Skip to content
This repository has been archived by the owner on May 7, 2020. It is now read-only.

Storage: support for migration helper #6878

Open
maggu2810 opened this issue Jan 25, 2019 · 0 comments
Open

Storage: support for migration helper #6878

maggu2810 opened this issue Jan 25, 2019 · 0 comments

Comments

@maggu2810
Copy link
Contributor

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 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.

Further notes:

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant