Scalability for Classes in LabVIEW

[paul.r]

Unless you are flattening a compiled version of the class, and are loading it into a built application, you are going to get the behavior of the current version of the class. 

[Mark_Yedinak]

---

@paul.r wrote:

Unless you are flattening a compiled version of the class, and are loading it into a built application, you are going to get the behavior of the current version of the class. 

---

This is true. I should have mentioned we use packed project libraries for our plugins. Another benefit of PPLs is that reduce your dynamic code to a single file. Much easier to distribute classes this way. Though working with PPLs does come with its own set of issues. Once those are resolved they work very well. They can be tricky to get your build environment setup correctly.

[juan_pablo_alvarez]

Hi Mark_Yedinak

I still have an issue, How do I load the data that its supposed to be stored as a flattened class into the database. I agree on storing the raw data as a json in case some other developer need it, but I still have to get the flattened class stored in the database.

Thanks

[Mark_Yedinak · Accepted solution]

Your class implementation would have methods to flatten/unflatten the data itself. Those methods would convert the data to JSON/XML/Key-Value Pairs or whatever format you want to use. That data would get stored into the database as raw data. In another table in the database you would store the flattened class itself. When storing the data and the class you would need to include a version number which will be used to load the appropriate class. If the classes are stored in the database then your application will need to retrieve them from the database and save them on disk so you can dynamically load them. If you go with the packed project library, which would be easier to store in the database since it is a single file, then you would simply need to save this file on your computer during initialization of your application. You can check to see if you have already done that and skip pulling the packed project library out of the database.

If you don't use a packed project library you will need to store all of the VIs that make up the class including and dependencies. If you do this you are essentially recreating a source code control system. If you don't want to use packed project libraries I would simply setup a source code control system and have your application checkout/update your local code copy and use that when you do the dynamic loading of your classes. Most of the source control systems have a command line interface or an API you can use to interact with it from within your application.

The other alternative as suggested earlier would be to create different executables and store that in the database. The executable is a single file (or at least only a few files) and easier to store than an entire VI hierarchy. The issue with this route though would components the executable rely on such as the LabVIEW runtime engine.

I would either go the PPL route and store those in the database or I would go a hybrid solution which is a combination of a source code control system and the database. I definitely would avoid creating your own source code control system. That would be a waste of time.