04-15-2024 04:03 PM
I've been working with LabVIEW for a while now, but this is my first project using DQMH and I want to make sure I'm following best practices as much as possible.
Say I have the following modules:
In all of these instances, I'm interacting with a database (in one way or another). I'm struggling to determine what's the best method of handling the cross dependencies of these modules.
Is it best to:
It seems to me like B or C are the two best options, as then there's either no dependencies between modules or the modules just depend on the shared library (which they might for other items anyways). Right now, C is seeming like the best option since it requires the least complex design choice even though it does create a singular dependency, but I know that zero-coupling is always more ideal.
Solved! Go to Solution.
04-15-2024 04:08 PM
If all the modules need to interact with the database, I see no reason why they can't all call your Database Interaction module, i.e. option A. There's nothing inherently wrong with a DQMH module depending on another DQMH module. It's a very common pattern that I describe briefly in Step 4 of my DQMH Quick Learning Path.
04-15-2024 04:30 PM
That's honestly my preference as that makes the most sense to me logically, so I'm glad to hear that's not a "bad" solution! Thanks for the quick response.
04-16-2024 06:07 AM
Option C or D are a lot simpler. Note that databases are designed to handle multiple connections using ACID principles. I've seen real-world cases where a "Database Interaction" component has added complexity while degrading capability (mostly by eliminating the ability to do parallel Transactions) and has produced no benefit whatsoever.
04-16-2024 07:45 AM
@drjdpowell wrote:
(mostly by eliminating the ability to do parallel Transactions)
In our HSE toolbox, we have a stand-alone DB DQHM module that each and every other module that needs DB access will start a separate clone of. That way, like James says, each module can have separate transactions.
You can have a look at the DB Example module in our open-source HSE Application Template. Let me know if that is interesting to you, and we can continue this discussion on the HSE Discord.
DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (Developer Experience that makes you smile )
04-16-2024 09:25 AM
@drjdpowell wrote:
Option C or D are a lot simpler. Note that databases are designed to handle multiple connections using ACID principles. I've seen real-world cases where a "Database Interaction" component has added complexity while degrading capability (mostly by eliminating the ability to do parallel Transactions) and has produced no benefit whatsoever.
That is a really good consideration actually. I should note that I don't foresee this application being able to access the database from multiple modules simultaneously (since its pretty user driven), so that probably isn't a concern. Nevertheless, something to consider and does make options C or D a bit more viable like you mentioned.
As @joerg.hampel mentioned though, making it a Cloneable module would solve that and is a fantastic idea. I actually really like the thought of it being a Cloneable, since that would clean up the communication channels I'm visualizing since then each module can spin up their own instance instead of trying to all communication back to a single instance.
This does bring up another question I have though: if I create a subVI for a Cloneable module, does that subVI need to be made re-entrant? I would assume yes.
Now I need to see if I can convert a Singleton to a Cloneable...
04-16-2024 09:44 AM
@ihyd-zmay wrote:Now I need to see if I can convert a Singleton to a Cloneable...
🙈🙈🙈
DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (Developer Experience that makes you smile )
04-16-2024 12:43 PM
I recently had to convert a Singleton module to a Cloneable. Unfortunately there isn't a scripting tool for this, so I had to do it manually. My module had a helper loop and roughly 6 requests/broadcasts. It took about an hour for me to re-create the module and copy the business logic over from the singleton to the cloneable.
04-16-2024 09:36 PM
I would ask the question - does it even need to be a DQMH module? Not everything in your program does. Could you not just wrap the database connection in a class and pass that around?
04-17-2024 02:51 AM
Having cloneable modules with separate database connections would solve the main problems, but I still don't see the point of the considerable added complexity. The advantage of an module would be the ability to do asynchronous db queries, but none of your three primary modules need or want that.