Enums are incorrectly treated upon database load #372
Comments
|
Hi |
|
Uh, I am confused. You are saying that the incorrect enum content is expected behaviour? OR even if they are serialized completely, I think it is an error to override the enum instances loaded in the JVM. |
|
I won’t say that restoring the persisted state of the enums internal values is wrong. That is the state of the enum and all objects referencing that enum when the data had been persisted. This way the persisted state can be restored without been altered by code changes. Btw there one trick: you can define the |
|
Ah yeah, thanks. Obvious workaround that I didn't think of. Anyway, let's look at another hypothetical scenario. Let's say I had two objects. One is created today (Day A) references Version 1 of the enum and is persisted. The second object is created tomorrow (Day B) and references Version 2 of the enum and is persisted. Both objects and therefore both versions of the enum would be in the database. According to the logic previously explained, both values would be correct, but only one would be loaded. |
|
It seems the storage manager doesn't quite handler this too well :D Shouldn't making a field transient behave the same way as removing a field? Removal would've worked with the heuristic approach afaik? What's different here? |
|
Never saw that crash with enums. Did you delete the old storage date before making a field transient? There might be some chase the LegacyTypeHandling can’t solve. I couldn’t reproduce that exception. Regarding enums and legacy type handling: |
|
I didnt delete the data before making them transient, i want to keep all data afterall. I also tried to figure out how to write a binary type handler for this case, but couldnt quite figure it out. At this point, I am not sure how to work around this. Also, if you really dont deem this a bug, which I still believe you should, given this example #372 (comment), maybe the documentation should point this out, to prevent others from running into this, as this is a major pain. |
|
I guess the legacy type handling reached its limits here. I don’t have a solution for that case, sorry. Here is a simple typeTandler that persists only the enum constant name for a specific enumeration. Maybe this can help: class MyEnumHandler extends AbstractBinaryHandlerCustom<EnumA>
{
public MyEnumHandler() {
super(EnumA.class, CustomFields(chars("enumConstantName")));
}
@Override
/**
* Persists enum constant name as string
*/
public void store(Binary data, EnumA instance, long objectId, PersistenceStoreHandler<Binary> handler) {
data.storeStringSingleValue(this.typeId(), objectId, instance.name());
}
@Override
/**
* Use persisted enum constant name to restore enum value.
*/
public EnumA create(Binary data, PersistenceLoadHandler handler) {
return EnumA.valueOf(data.buildString());
}
@Override
/**
* Used to register the enum constants as roots.
* Return empty array to skip regstering
*/
public Object[] collectEnumConstants() {
return new Object[0];
}
@Override
public void iterateLoadableReferences(Binary data, PersistenceReferenceLoader iterator) {
//nothing to do
}
@Override
public void updateState(Binary data, EnumA instance, PersistenceLoadHandler handler) {
//nothing to do
};
}To setup: EmbeddedStorage.Foundation(WORKDIR)
.onConnectionFoundation(f -> f.getCustomTypeHandlerRegistry().registerTypeHandler(
5BB0
new MyEnumHandler()))
.start(); |
Uh oh!
There was an error while loading. Please reload this page.
Environment Details
Describe the bug
Enums seem to be persisted the first time they are encountered, not reflecting any changes on the enum fields.
I have an enum in which I have a collection. I added an item to the collection, but at runtime, its the old collection, without the added item.
If I print it first thing in
main, it shows the new value. Once EclipseStore started up, the enum values were replaced with the persisted ones it seemed.To Reproduce
EnumA.A2.B2Expected behavior
Enum values should always represent the same state as they did before restoring eclipse store data.
The text was updated successfully, but these errors were encountered: