We need to think about a more general solution or at least some support for that in the UI.
Here an idea -- the idea has not been proofed if possible, I just write about it so it does not get lost.
The classes that are stored should implement the Serializable interface.
Our storage implementation then can not only store the class name of the value that is stored but also its serialVersionUID.
All the time the class used on a storage is changed in an incompatible name, we should change the serialVersionUID.
If a storage tries to deserialze a class it checks if the serialVersionUID of the stored and the class used for restore fits.
If it fits, the new instance can be created as usual.
If it does not fit, it should try to migrate the stored data.
Migration helpers will be added that
provide old class name
provide old class serialVersionUID
provide a class of the old type (name + serialVersionUID) or a classloader that provides that class
provide a new class name
provide a new class serialVersionUID
provide a method that takes an instance of the old class and returns an instance of the new class
A migration manager can consume all migration helpers and try to find a chain to migrate from old to current (perhaps using migration_helper_from_old_to_x, migration_helper_from_x_to_y, migration_helper_from_y_to_current).
The storage implementations just need -- if the versions does not fit -- to take the "classloader" or "class" of the old type from the migration manager to deserialize what has been stored (this should succeed).
After that it calls the migration manager to migrate it to the current expected class instance.
After that the new value could be stored (so we don't need to migrate again) and the new instance can be returned.
Some time the rule classes used to store / restore has been changed.
In my fork I added a small code change so I could still load from an old storage: https://github.com/maggu2810/smarthome/commit/5ca7a0816b271b155f919a14b01d3fce77fc49ad
We need to think about a more general solution or at least some support for that in the UI.
Here an idea -- the idea has not been proofed if possible, I just write about it so it does not get lost.
The classes that are stored should implement the
Serializableinterface. Our storage implementation then can not only store the class name of the value that is stored but also itsserialVersionUID.All the time the class used on a storage is changed in an incompatible name, we should change the
serialVersionUID.If a storage tries to deserialze a class it checks if the
serialVersionUIDof the stored and the class used for restore fits. If it fits, the new instance can be created as usual.If it does not fit, it should try to migrate the stored data.
Migration helpers will be added that
serialVersionUIDserialVersionUID) or a classloader that provides that classserialVersionUIDA migration manager can consume all migration helpers and try to find a chain to migrate from old to current (perhaps using migration_helper_from_old_to_x, migration_helper_from_x_to_y, migration_helper_from_y_to_current).
The storage implementations just need -- if the versions does not fit -- to take the "classloader" or "class" of the old type from the migration manager to deserialize what has been stored (this should succeed). After that it calls the migration manager to migrate it to the current expected class instance. After that the new value could be stored (so we don't need to migrate again) and the new instance can be returned.
Further notes: