Support for old models after renaming component classes

[Stan]

After the components were renamed in the SON models, the older models have stopped loading.
In future we need some mechanism to avoid such problem. (define the synonym list?)

[Ivan Poliakov (mech)]

I think this is the expected and correct behaviour for the reflection based serialisation system. Because the components' class names are the only available identifiers of their type, renaming components is not something that can be taken lightly.

A robust way to handle this would be to version model plug-ins more rigorously. Any fundamental change such as the change in the supported component set must be treated as a new, incompatible w.r.t. the file formats model and a new version tag in the model code (so ideally the plugins should not be in the core source tree), while the old version that works with the older file format must still be able to be instantiated if needed. This way a very lightweight model transformer can be written that would upgrade the model instances to newer versions.

A quick but dirty solution is to simply unzip the .work file and use sed to replace the class names (provided only the names have changed).

[Danil Sokolov (danilovesky)]

I also faced this problem when decided to rename one of STG classes (due to a spelling error). As expected, the old STG models failed to load after the change. As a temporary solution I sought about adding the list of class-name aliases (or synonyms) into the deserialiser. However, the deserialiser is on the critical path of many functions (copy/paste, undo/redo), so not a good idea to check against a list of aliases there.

I think "versioning" the plugins, as Ivan suggests, is a bit over-complicated for the current state of development (with a couple of active contributors) and exploitation (a dozen of end users). External conversion with sed is what I did for STG changes, but this may be too difficult for the users.

What if we do conversion on the load of the work files? Each model may register a list for synonyms (Map<String,String> oldToNewClassName ) in the Framework and at the file load, before deserialisation, the Framework unzips the stream, goes through the model XML to replace the class names, zippes the stream back and passes it to the deserialisation procedure.

[Ivan Poliakov (mech)]

That would work in this particular case of course, but as a general solution that would be very unsafe and difficult to maintain.

By "versioning" I meant simply checking out the older model code that is known to work with the old file versions and adding it as a standalone model (e.g. "SONs 1.0 (deprecated)"). This would allow Workcraft to still load the old files automatically, but the model could be flagged as "deprecated" to show a warning message on load and recommend a conversion to the newer model which could be implemented as an exporter.

The only issue is that the newer model class will have to be renamed to something like SON2 to make it distinct from the old one.

[Ivan Poliakov (mech)]

Changing class names is not even necessary, a package name change would work as well - e.g. org.workcraft.plugins.sons.v1.*