LVOOP Class Versioning, saving to file

[Synaesthete]

I'm storing LabVIEW objects to file.  What is the best way to re-load these objects even if the class version has changed?  Generally I've found that this causes few problems and the classes are able to adapt, except when I've made major changes to the class definition typedef.  Is there a way to write an adapter VI that checks the class version of the stored class and up-converts appropriately?

Also, are there any good resources for general "best practices" related to LVOOP, for versioning, working as a team, etc.?

[timtamslam]

Hey there Synaesthete,

Here's a couple places for info regarding LVOOP: 

LabVIEW Object-Oriented Programming: The Decisions Behind the Design - http://zone.ni.com/devzone/cda/tut/p/id/3574

LabVIEW Object-Oriented Programming FAQ - http://zone.ni.com/devzone/cda/tut/p/id/3573

Applying Common Object-Oriented (OO) Design Patterns to LabVIEW - https://decibel.ni.com/content/docs/DOC-2875

And about your question, what kind of file are you storing the LabVIEW objects too? When it comes to re-loading your objects you may want to look into dynamically loading classes. There is a section about that in the first link above under the section labeled "The Design of a LabVIEW Class". 

Hope this information helps!

[Synaesthete]

Thanks so much!  That section on dynamic classes is exactly what I was looking for.  I'd read that a while back but couldn't find it for some reason.

I'm basically doing exactly what it describes, with loading classes in to a frame-work using a plugin architecture.  I'm storing some objects within objects on an array, and then writing a sort of "master object" to a binary file.  Since my customer may have older data files and the classes may be modified over time, I need to ensure that the old data files will load properly.  I have had 'some' trouble with doing this; occasionally the data seems corrupted or incorrect when loading older data files.

What I would really like is a way of creating a general class manager.  This manager would be able to check class versions, up-convert class data in a more specific way, and handle loading class data for child classes that may not be available in a particular user's installation.  That section on dynamic loading certainly helps lead me in the right direction, but perhaps you have a bit more insight on my strategy?

[timtamslam]

Hey Synaesthete,

Glad you found some useful information in those links. Don't forget our main website can turn up a lot of useful tutorials and knowledge basis when using our search function! Definitely search there in the future if you have other questions. 

I'm not super familiar with what you're trying to achieve but have you considered Subversion (SVN)?

https://decibel.ni.com/content/groups/large-labview-application-development/blog/2010/03/29/using-su...

You could certainly use it to do comparisons of versions but i'm not sure if it would specifically help you create a class manager.

[Matt_W1]

Unfortunately when loading previous classes there doesn't seem to be a way to have tight control over how old versions are converted up. The conversion (hopefully I remember the details right) depends on how they where changed within the editor, if you rename a field then the data for the old name when be placed into the new name, if you remove the field and replace it then the data for the old filed will be deleted and the new one will take the default value).

You'll want to avoid typedefs (classes should be fine) within class data, since typedefs don't maintain their mutation history.

http://lavag.org/topic/14548-class-mutation-history/

Enums can also be a problem

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Maintain-Mutation-History-as-part-of-Enum-Type-Definit...

Hopefully some version of LabVIEW will allow more control over version mutation, but currently you would need to be very careful with the the class data. SVN (or some other file versioning system), could be helpful for backtracking if you mess up modifying the class data (just don't go before the last in use version, since that may break the mutation system).

To have to full control you would need to flatten your data manually. If you want to go that route converting things to variants then using flatten to string is a simple way of storing type data with the real data.

[Synaesthete]

Some interesting reading there... I wish I'd known about that before implementing my classes!  I have type defined enums and type defined clusters all over the place.  This hasn't really caused many issues except for some occasional weirdness (that I can definitely now attribute to mutation errors), but going forward I am definitely going to change my technique.

I would just like a simple class mutation adapter; this could be a VI (stored in the class) with one version of a class's data on the input, and another version of class data on the output.  Then, I could wire up or perform any intermediary conversion I choose between those data clusters.  This functionality would not need to supercede the existing auto-mutation functionality, and would probably use the mutation data as it is, just with the ability to access and control the mutation process when necessary.  This would dramatically facilitate design changes without rendering valuable customer data useless.  In the case of an application that might have a long future ahead, it would prevent old data files from going out of style like a floppy.