Scalability for Classes in LabVIEW

[paul.r]

If I am understanding correctly, it sounds like he is trying to save the state of the software in the database along with the data - so run some test maybe, collect the data with it (and get data from the DB to run the test), and then be able to go pull the software from that time and re-run with that data set, with the expectation that the application would run exactly as it did when the original test was run. 

I think a better solution is using a version control system, and just storing the application version in the database.

[juan_pablo_alvarez]

It makes sense, but, the info I store would mean like 100+ columns, I think its better to encapsulate all info into a BLOB an whenever I needed I just have to unflatten to a parent class and let the dynamic dispatch take control of reading and selecting the methods (vis) the class needs.

Thanks

[Mark_Yedinak]

There are other more flexible solutions. You could store the data as key/value pairs.This would requires lots of rows for the table but the at least it is usable by other applications. Another alternative is to flatten the data to JSON or XML and store that. Again, anything can act on the data. Storing the class definitely restricts you to LabVIEW only interaction with the database.

[paul.r]

Except thats not how dynamic dispatch works. The class mutation history allows you to open an old version of a flattened class, but it is still going to use the current version's methods.

What does this class do that you need to be able to go back to different versions of it? Why don't you just store the application version in the database?

[paul.r]

---

@Mark_Yedinak wrote:

There are other more flexible solutions. You could store the data as key/value pairs.This would requires lots of rows for the table but the at least it is usable by other applications. Another alternative is to flatten the data to JSON or XML and store that. Again, anything can act on the data. Storing the class definitely restricts you to LabVIEW only interaction with the database.

---

I could be wrong, but I don't think you are understanding what he wants to do. He is specifically storing the class in the database because he wants to be able to go back to a point in time, get the version of the class as it stood at that point in time, and run the code with that version and have it behave as it did then. 

[juan_pablo_alvarez]

Hi paul.r

I'm attemting to store only the collected data, the software behaviour will be modified by the dynamic distpatch property itself, for instance, the flattened class retrieved with the record number 1 of the year 1998 is suposed to take the data and apply a function 1(vi). The record number 200 of the year 2000 is suposed to take the data and apply the funcion 2(vi). whenever I query the database for the record 1 or record 2, the dynamic dispatch property of classes would use the right function(vi). 

The only disadvantage I think, it's that from record 1 to record X, the classes stored with them must have the same parent, or worse, each class must be the parent of the next one, taking into account that the need for a new class is related with the modification on the functions(vis) that operate on the data.

The reason I opened this post It's because It seems odd, and I wanted to have some advice from more experienced developers.

Thanks

[Mark_Yedinak]

---

@paul.r wrote:

---

@Mark_Yedinak wrote:

There are other more flexible solutions. You could store the data as key/value pairs.This would requires lots of rows for the table but the at least it is usable by other applications. Another alternative is to flatten the data to JSON or XML and store that. Again, anything can act on the data. Storing the class definitely restricts you to LabVIEW only interaction with the database.

---

I could be wrong, but I don't think you are understanding what he wants to do. He is specifically storing the class in the database because he wants to be able to go back to a point in time, get the version of the class as it stood at that point in time, and run the code with that version and have it behave as it did then. 

---

I do understand that. What I am saying though is that his solution limits everything to only using LabVIEW. What if at some later date they want to do other analysis on the data that has been collected? If it is stored as a flattened LabVIEW class, NOTHING can analyze that data except a LabVIEW application with that class. While his solution sounds appealing, it is very restrictive. Storing the data as data, ANYTHING can work with that data now or in the future, not just his LabVIEW application. What is the point of storing data in the database is only one application will ever be able to work with that data? I am advocating for rethinking the solution a bit so that in the end it is more flexible. He can still have his class hierarchy for working with the data in his application. Another piece of data that can be stored in another table is the version of the class to retrieve the data that corresponds to that version. Heck, he can even store that flattened class in the database. What I am suggesting he not do is to keep the data in the flattened class. That is EXTREMELY restrictive.

[paul.r]

---

@Mark_Yedinak wrote:

---

@paul.r wrote:

---

@Mark_Yedinak wrote:

There are other more flexible solutions. You could store the data as key/value pairs.This would requires lots of rows for the table but the at least it is usable by other applications. Another alternative is to flatten the data to JSON or XML and store that. Again, anything can act on the data. Storing the class definitely restricts you to LabVIEW only interaction with the database.

---

I could be wrong, but I don't think you are understanding what he wants to do. He is specifically storing the class in the database because he wants to be able to go back to a point in time, get the version of the class as it stood at that point in time, and run the code with that version and have it behave as it did then. 

---

I do understand that. What I am saying though is that his solution limits everything to only using LabVIEW. What if at some later date they want to do other analysis on the data that has been collected? If it is stored as a flattened LabVIEW class, NOTHING can analyze that data except a LabVIEW application with that class. While his solution sounds appealing, it is very restrictive. Storing the data as data, ANYTHING can work with that data now or in the future, not just his LabVIEW application. What is the point of storing data in the database is only one application will ever be able to work with that data? I am advocating for rethinking the solution a bit so that in the end it is more flexible. He can still have his class hierarchy for working with the data in his application. Another piece of data that can be stored in another table is the version of the class to retrieve the data that corresponds to that version. Heck, he can even store that flattened class in the database. What I am suggesting he not do is to keep the data in the flattened class. That is EXTREMELY restrictive.

---

Ah, gotcha - I may have misunderstood - I assumed he was saving data separately, along with the class - test conditions/setup data in one table/column, results in another, and the class in another. If he is storing the data in the class, I agree that is a very bad solution.  

[juan_pablo_alvarez]

Hi Mark Yedinak,

I REALLY understand your point, my question is: If I store the data as flattened json, and, in other column the version number, I would need to have a case structure to match the version number with the proper class, so how to make use of dynamic dispatch?

Thanks

[Mark_Yedinak]

No, you wouldn't. Use dynamic loading to load the desired class from disk. Part of the name of the class on disk would include the version number of the desired class. Basically you want to create a plugin architecture. You gets the benefits of dynamic dispatch while getting the flexibility of using the data in other applications.

Part of doing this is to create a helper VI which outputs the desired version of the class. The connector pane would have the base class version marked as a dynamic dispatch connector. Inside the VI you have a constant which is the base class then dynamically load the desired version from disk and output that. The rest of the application uses the methods with dynamic dispatch.

The basic loading VI would look something like this.