Update Entity references if we change the type of an entity

Hello,

we must change (extend) our entity model and therefor we convert the type of some entities.

As example (like in the attached example):

We have an EntityA that have a reference to an EntityB.

But now we introduced as example a new Entity NewKindOfEntityB. And we have a defined logic how we detect the existing EntityB instances they must be converted to the new Entity. With the same ID, because it's possible that many other entities have just a ID based reference with a simple 'int' field to this element. And we thought that also the real references are based on the ID.

This step is done by our updateDB (we call this step profileMigration)

But after this conversion, the reference from EntityA to an EntityB (which is now a NewKindOfEntityB (subclass of EntityB) is broken. The ObjectDB explorer still show as Entity Class the 'EntityB' with the correct ID, but all fields are empty.

For us it would be a very hard challenge to find all references they could be involved, because we use inheritance a lot.

Is it possible that you can provide a fix?. We think it must be possible to detect that the reference is 'broken' and then try to refresh the reference.

A one file example to demonstrate the scenario is attached.

The example contained a small Copy-Paste issue.

It is solved in the new attachment.
 

We are close to our next release, so we want to know if we need start implementing a workaround, whether you consider the behavior? If you already consider this, it would be helpful if you can tell us your assessment for a patch.

Hello ObjectDB,
Please let us know if you are working on this issue.
For us (and our release) this is a critical issue.

Best regards,
  BTC Embedded Systems AG

References to entity objects are implemented by ObjectDB as a pair of (type + id) rather than just an id. This enables faster navigation between objects, as retrieval of an object is faster when its exact type is known.

Following your request we added a new option to version 1.7.0_02, which can be enabled by setting a system property before accessing ObjectDB:

        System.setProperty("objectdb.temp.extended-ref-retrieval", "true");
            // or by using the -D JVM argument

When this option is enabled retrieval of objects by a reference accepts the expected type as well as its subclasses and your sample test passes.

However, please note that:

• It may slow your application.
• Object IDs will have to be unique per entity type hierarchy rather than per type.
• There could be other (unknown yet) side effects.

In the short term this is the best solution we can offer. Maybe it could be useful to you in a migration process, in which relevant EntityA instances will be marked as dirty and changes will be committed. So after the database update your application can be used with this option disabled.

Hello,

the version with the new property can't not be used. We get exceptions for valid references.

Example to demonstrate the error is attached.  (We think the issue occurs if a referenced entity have a reference to another entity)

We need a fix that fulfills the requirements for a stable version.

Will they be a more elegant solution in the long term? We think we need this kind of modifications in the future again.

As stated above (#5), with this option enabled "Object IDs will have to be unique per entity type hierarchy rather than per type.", but in your example there are 3 objects in the same type hierarchy with the same id #2.

Unfortunately this is the best solution we can offer now.

There are 3 objects with ID #2 ?

We simplified the example.

We look into the DB and we have just 3 Objects:
EntityC with id #3
EntityB with id #2
EntityA with id #1

What is the issue in this (simplified) example?

Sorry, you are right.

After further investigation of this issue, unfortunately it seems that we cannot provide a quick implementation of this type of automatic schema evolution at the moment, as critical parts of ObjectDB currently require references to include the exact type of the referred object.