Backwards Compatibility of Class Data -- After Name Change

[_carl]

With LabVIEW classes, I appreciate that:

- I can save and load class data to/from disk.

- Backwards compatibility is automatically taken care of with no coding required (in most cases).

However....this functionality breaks as soon as you rename a class (which includes moving it into a library).

It'd be great if I could rename a class (or add it to a library) and then still load data that was saved with a previous version of that class.  I've been burned by this a few times where legacy data files are unrecoverable after code refactoring....  and it's a tradeoff I'd rather not have to make in the future!

(Apologies if this suggestion has already been submitted...but...didn't find it in my search)

[AristosQueue (NI)]

I spent a long time trying to do this in the early days of LV classes. What you request is logically impossible. Once a class is a different name, it is entirely possible (indeed, in some cases likely) that another class has that name. To follow across a rename, we would need the flattened data to contain a guid of some sort, but that becomes extremely error prone for a whole different set of reasons (NXG did some attempts along that route).

At the end of the day, a class has an identity. Once it has a different identity, it isn't the same class.

For the record, a class does store its rename information... that information is only used when it is an ancestor class trying to unflatten data. But the leaf-level class (which is what you care about) has to have the exact name, and I know of no trickery to automate.

(I even tried automating the frustrating "lvlib -> lvlibp" transformation and someone complained that they were trying to load both the built and unbuilt class at the same time and it was confusing their unflatten code.)

I really don't think there's anything to be done to improve this situation. It's a problem that exists across computer science with persisted data.

[AristosQueue (NI)]

Now, having said all of the above... if we step away from automate and into "let me define the transform", then there's a possibility...

Let's say you rename class X to class Y. We could potentially let you create a new class X that has a special "Translate Unflatten" method. When data of class X is encountered, it would unflatten as per the new class X (and we could preserve the mutation records of the original class X), and then run the translate method. In the translate method, you would write code to shuttle the fields into a new Y object.

This mechanism would ensure that the X namespace was filled and no other class named X could load into memory, which is the crux of the automation difficulty.

[AristosQueue (NI)]

PS: I said "logically impossible." I should say "logically impossible as far as I can tell." It's hard to prove that there is no solution! If any of the above inspires you to see a solution, please, post it. I'm not above revising my theory here to improve rename handling.

[_carl]

Thanks for the detailed response!

What you say makes sense, and it is pretty clear that, with a case like this (where the file is a child class):

that you couldn't ever realistically expect to load a class after a rename. You couldn't necessarily expect for that class to be in memory, and you wouldn't know where to find it on disk. And, by extension, you'd run into the same issue for any renamed child class. So...I concede, my original request is probably "logically impossible".

However, let's say that you're trying to load a class and you have:

1) An instance of the latest version of the specific renamed class

2) Flattened data from a previously-named version of that class (and not a child class).

What if there was a "Load Exact Class" VI such that, assuming the above, would actually load that data?

Something like this would at least give you a very-usable mechanism for recovering data from renamed classes, even if you had to put some work into your code to cover all child-class cases.