Questions about data model evolution

[rpx99]

I have had a look at the legacy mapping.

Currently trying out a few things, including renaming my class "Customer" -> "Customers"

Since this case is not handled automatically (correct?), I would like to test the variant with the "refactorings.csv" as described at https://docs.eclipsestore.io/manual/storage/legacy-type-mapping/index.html

Small note: The "old" or "current" is only intended here for clarification - perhaps it should be mentioned that it does not belong in the file but only the actual mapping data.

old current
com.my.app.entities.OldContact com.my.app.entities.NewContact

My own file now looks like this:

de.example.demo.model.Customer de.example.demo.model.Customers

Nevertheless, I still get the following "mapping" error:

Unexpected error occurred: org.eclipse.serializer.persistence.exceptions.PersistenceException: Missing runtime type for required type handler for type: de.example.demo.model.Customer
        at deployment.demo.war//org.eclipse.serializer.persistence.types.PersistenceTypeHandlerManager$Default.validateExistingType(PersistenceTypeHandlerManager.java:390)
        at deployment.demo.war//org.eclipse.serializer.persistence.types.PersistenceTypeHandlerManager$Default.ensureTypeHandler(PersistenceTypeHandlerManager.java:439)
        at deployment.demo.war//org.eclipse.serializer.persistence.types.PersistenceTypeHandlerManager$Default.lambda$ensureTypeHandlers$2(PersistenceTypeHandlerManager.java:486)
        at deployment.demo.war//org.eclipse.serializer.collections.ChainStorageStrong.iterate(ChainStorageStrong.java:1316)
        at deployment.demo.war//org.eclipse.serializer.collections.HashEnum.iterate(HashEnum.java:693)
        at deployment.demo.war//org.eclipse.serializer.persistence.types.PersistenceTypeHandlerManager$Default.ensureTypeHandlers(PersistenceTypeHandlerManager.java:485)
        at deployment.demo.war//org.eclipse.serializer.persistence.types.PersistenceTypeHandlerManager$Default.ensureTypeHandlersByTypeIds(PersistenceTypeHandlerManager.java:477)
        at deployment.demo.war//org.eclipse.store.storage.embedded.types.EmbeddedStorageManager$Default.ensureRequiredTypeHandlers(EmbeddedStorageManager.java:344)
        at deployment.demo.war//org.eclipse.store.storage.embedded.types.EmbeddedStorageManager$Default.start(EmbeddedStorageManager.java:251)
        at deployment.demo.war//org.eclipse.store.storage.embedded.types.EmbeddedStorageManager$Default.start(EmbeddedStorageManager.java:95)
        at deployment.demo.war//org.eclipse.store.integrations.cdi.types.config.StorageManagerProducer.storageManagerFromProperties(StorageManagerProducer.java:97)
        at deployment.demo.war//org.eclipse.store.integrations.cdi.types.config.StorageManagerProducer.getStorageManager(StorageManagerProducer.java:63)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)

The parser for the .csv can certainly handle a lot of options (separators etc.). I have already tried a , and a ; but none of them work:

de.example.demo.model.Customer,de.example.demo.model.Customers
de.example.demo.model.Customer;de.example.demo.model.Customers

Calling up or reading the file itself works via :

    @Override
    public void customize(EmbeddedStorageFoundation<?> embeddedStorageFoundation) {
        //embeddedStorageFoundation.setDataBaseName("test123");
        var refactoringFilePath = Paths.get("/home/rpx/Downloads/node1/store/refactorings.csv");
        embeddedStorageFoundation.setRefactoringMappingProvider(Persistence.RefactoringMapping(refactoringFilePath));
    }

I also have other issues, but I would report them separately (if I don't get it right), e.g. there seems to be no automatic type change from

private String number = String.valueOf(new Random().nextInt()); -> private Integer number = new Random().nextInt();

Here I assume you have to intervene via the explicit mechanism?

And if you remove a field, the data is not deleted (as with a drop of a column of a relational DB table), but it seems to behave more like a VIEW where the column has been removed / excluded?

If I have understood the concept correctly, the data in the store (physically) is not "touched / changed" by the evolution of the data model, but everything is resolved / regulated "on-the-fly" via the entries in the PersistenceTypeDictionary.ptd ?

[hg-ms]

Hello,

Regarding the refactorings.csv file format:
The headline “old current” is required. As separator you should use a single tabulator.

There is no automatic conversion from String objects to primitive integer values.
This must be done by a custom BinaryValueSetter.

The LegacyTypeMapping does not modify the persisted data. The mapping is done during object re-creation in memory. If such a mapped object is stored again it will be written in its new version. The obsolete old version will be removed by the storage garbage collector someday.
The PersistenceTypeDictionary is essential for that as it describes the layout of all persisted types.

[rpx99]

Thanks a lot for your comments. Mapping works now!