DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Coupling Best Practices

Solved!
Go to solution

One reason it makes sense to be an async module is for database connection management. I've worked with a cloneable database module where each clone manages the database connection, which also gives you the ability to do more sophisticated behavior like automatically attempting reconnects if the connection is lost, transparent to the end user of the public API of the database module.

0 Kudos
Message 11 of 19
(323 Views)

I'm glad this stirred up so much conversion! I'm really enjoying the discussion.

 

Yeah, that was my thought as well. If I create it as a DQMH module, then I gain the flexibility of asynchronous calls if needed and then the module can do things like maintain the connection reference, handle errors, etc. all within the module itself so the caller doesn't have to manage all of that or even know how it works. Plus, then I can do some unit testing to verify my database connectivity is working as expected (which I could do with a class like @Taggart mentioned, but the DQMH API Tester is a nice bonus). Plus, then I have access to the other DQMH extra like the validation tool as well.

 

@drjdpowell - This is probably more complex than it really needs to be for this application, but most if not all of the applications I'm developing these days have database interaction in them, so the reusable module could come in handy for future development. While you're right that I don't need any asynchronous calls at the moment, future me might and I should really look out for him more!

0 Kudos
Message 12 of 19
(315 Views)

@Darren wrote:

One reason it makes sense to be an async module is for database connection management. I've worked with a cloneable database module where each clone manages the database connection, which also gives you the ability to do more sophisticated behavior like automatically attempting reconnects if the connection is lost, transparent to the end user of the public API of the database module.


That makes sense.

 

I mostly use SQLite (Thank you Dr. Powell!) so managing connections is generally not an issue.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 13 of 19
(293 Views)

@Taggart wrote:

@Darren wrote:

One reason it makes sense to be an async module is for database connection management. I've worked with a cloneable database module where each clone manages the database connection, which also gives you the ability to do more sophisticated behavior like automatically attempting reconnects if the connection is lost, transparent to the end user of the public API of the database module.


That makes sense.

 

I mostly use SQLite (Thank you Dr. Powell!) so managing connections is generally not an issue.


Although as I am writing this I recall a project I did recently that used SQLite where I did have a database module - not for connection issues, just a general architecture decision I made and I can't even recall why. Singleton though, not cloneable. And I did wrap the database in a class, but instead of passing the class around to all the modules, I wrapped it in a DQMH module and sent requests - maybe to offload DB overhead to a parallel thread?

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 14 of 19
(292 Views)
0 Kudos
Message 15 of 19
(279 Views)


Although as I am writing this I recall a project I did recently that used SQLite where I did have a database module - not for connection issues, just a general architecture decision I made and I can't even recall why. Singleton though, not cloneable. And I did wrap the database in a class, but instead of passing the class around to all the modules, I wrapped it in a DQMH module and sent requests - maybe to offload DB overhead to a parallel thread?


I find wrapping a class inside a module easier.

 

Because if you have a class available to multiple modules, then you're stuffing around with DVRs and breaking the dataflow.

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

0 Kudos
Message 16 of 19
(264 Views)
Solution
Accepted by ihyd-zmay

@Ozfarmboy wrote:

 

Because if you have a class available to multiple modules, then you're stuffing around with DVRs and breaking the dataflow.


My main suggestion is don't share database connections between modules, because databases are designed to work with parallel code running through independent connections.  My secondary suggestion is that more complicated solutions to support vague ideas of possible future advantages has a very high chance of turning out to be a negative.  Your DVRs don't sound any simpler than a module. 

 

I would just use a simple class with a DB connection inside it, with each code module making an independent connection to the DB.  No sharing.  

Message 17 of 19
(259 Views)

After playing with the implementation some, you're absolutely correct. Making it a module and launching that module from every place I need to interact with a database became a bit cumbersome. I've wrapped the functionality into a class and am just creating a unique instance of the class anytime I need a database connection now.

 

The thing that really motivated the class creation is that if I do ever need a module, I'll just wrap the class into the module's private data and the core functionality remains the same. The module then just acts like an API for the class.

 

Thanks Dr. Powell!

Message 18 of 19
(249 Views)

@drjdpowell wrote:


My main suggestion is don't share database connections between modules, because databases are designed to work with parallel code running through independent connections.    


That's a good point.  I've always previously thought of a database as a single access point, much like we might treat a hardware device reference. But no, it's parallel.  

 


@drjdpowell wrote:

Your DVRs don't sound any simpler than a module. 

Agree.  That's what I was trying to say!

 


@drjdpowell wrote:

I would just use a simple class with a DB connection inside it, with each code module making an independent connection to the DB.  No sharing.  


I like this.  

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

0 Kudos
Message 19 of 19
(231 Views)