Scalability for Classes in LabVIEW

[juan_pablo_alvarez]

Greetings, 

I'm storing some data in the data member cluster of a class called "class1" of version "1", this object is being saved in a binary file. Knowing that this class could be modified to add or delete info from it, for example "version 2", I need a way to load any file containing this object of any version, and that labview could load its data without crashing.

For that I have considered using dynamic dispatch vis for every class but this would mean that any version is a new subclass of the previous version.

Example:

- class1_version1(base)

  - class1_version2(add data)

    - class1_version3(add data)

      - class_version4(remove data)

        - class1_version5(change type of data)

          - etc

Imagine this process over time where I could have over 20 or 30 subclasses. This is not a posibility for me, so here is the question:

Is there another way using classes and dynamic dispatch vi to overcome this problem?

Thanks a lot for your time.

[paul.r]

Version information is stored inside class data, unless I am misunderstanding you. Why would you need different classes for each version?

[juan_pablo_alvarez]

Hi , thanks for your time,

This is the use case:

My system produces an object of class "Payload" that stores a DBL array. When I load this file I want LabVIEW to show (without telling it) the front panel of a vi showing the array. I accomplish this by using dynamic dispatch.

A month later I added to the Payload class a String array. So, if I load a file containing this object, LabVIEW will load it without problem, but if I load the previous file which contains the previous "version" of the Payload class Labview will certainly crash because the object class mismatch, that's why I would need a new subclass for each version, to take advantage of the dynamic dispatch functionality.

[drjdpowell]

Are you aware of the inbuilt mutation history of classes?  LabVIEW will not crash if you load flattened data from an old version.  

Only if you are not using the inbuilt flattening function, would you need your own mutation design.

[juan_pablo_alvarez]

Hi, I don't know what functionality you are talking about, 

Can you point me to any knowledge document or any related information about that?

Thanks

[paul.r]

You really shouldnt need to do anything special, the functionality is already built in. How are you flattening/unflattening the classes? Has it actually caused LabVIEW to crash on you or you just thought it would? 

http://www.ni.com/white-paper/6316/en/

[juan_pablo_alvarez]

Hi, 

I thought it would crash, however what I could understand from the paper you thankfully point me about, It doesn't apply any dynamic dispatch functionality to the vis I would need. Following the last example I proposed, when I add some data to the private cluster, I want that version of the class to create a report with an image, however, if the class loaded from file doesn't have that specific data, the report would generate as text. This is the funcionalityt I'm aiming.

Thanks in advance

[paul.r]

If I am understanding correctly, you want to be able to take a class with method x, and flatten it to disk. Then update the class so that method x does something completely different. Then flatten to disk, and unflatten either class and get the behavior that was in the class when you flattened it?? 

Why do you want this functionality?? No offense, but this doesn't seem like a great design. Why not just use different classes all together?? GenerateReportWithImage.lvclass, GenerateReportwithText.lvclass?

[juan_pablo_alvarez]

Hi, 

I can't justify why I see it so necessary.

I'm going to flatten the class to a byte array so I can put it into a database. The idea is to be backward compatible through time with any change I do to the data stored into a class, I'm just trying to get alI I can from the dynamic dispatch property of classes. When someone in the future needs to take the data from the database of an old record I want to be sure that the software behave like it used to be with that version of the class.

Thanks in advance

[Mark_Yedinak]

Wouldn't storing the flatten classes in the database lock all database access into using LabVIEW? Wouldn't it be better to only store the data itself in the database? That any any application could work with the data. By storing the flattened class in the database nothing else can really make use of the data.