Best practice: Database update/migration of embedded databases in products

Hello Support,

what experience do you have for data migration within a product?

An example:
There are three versions of a product (v1.0; v1.1, v2.0).
In each version, the entities have been modified. Attributes added, removed and renamed. If attributes were removed, then only because the data is now held otherwise.

The product store user data in the ObjectDB-Database.
Example:
V1.0: EntityPerson{ String firstName;  String familyName; String address; }
    DB1: [firstName=”Max”; familyName=”Mustermann”; address=”26135 Oldenburg”]
V1.1:  EntityPerson{ String name; String address; }
    DB2: [name=”Max Mustermann”; address=”26135 Oldenburg”]
V2.0: EntityPerson{ String name; String zip; String city;}
    DB3: [name=”Max Mustermann”; zip=”26135”; city=”Oldenburg”]

How can we load the Database DB1 with the Product in Version 1.1 or 2.0 with the new “EntityPerson” Class and without data loss?
We have a few ideas, but we think you have experience and advice on how this can be solved well.

Do you have any example that illustrates the procedure for data migration (Also throughout several versions.)?

Best regards, BTC-ES

The ObjectDB schema evolution support consists of:

• Automatic schema evolution - for adding and removing fields and for class hierarchy change.
• Configuration schema changes - for renaming packages, classes and fields.

The scenario in your post, of merging and splitting fields, is not covered directly and requires some code in your application. In order to support this schema change you will have to maintain all the fields, (the old and the new) in the new schema, and use a JPA event callback to make the conversion.

In V1.1 your class will include the following fields: firstName, familyName, name and address, and a conversion of firstName and familyName in a PostLoad callback (if not null) to name. Only name will be used by the application (except in the conversion callback method).

Similarly, in v2.0, your class will include the following fields: firstName, familyName, name, address, zip and city, and a conversion of address to zip and city in a PostLoad callback (if not null).

If conversion is restricted to V1.0 -> V1.1 and V1.1 -> V2.0, but not V1.0 -> V2.0 directly, and you make sure that on upgrade all the old objects are converted and stored in the database in their new form, you can remove the fields firstName and familyName from V2.0.