Database corrupted after schema change

Greetings,

a very strange problem happened to me after I moved an interface in the hierarchy of an entity class.

The original structure of the Entity was:

@Entity public class TC extends AbstractTC { 
    private String tableId;
    private transient boolean isUpdating = true;
}

public abstract class AbstractTC extends BDOWA { 
    private transient boolean isEditable = false;
}


@MappedSuperclass public abstract class BDOWA extends BDO { 
    @ElementCollection
    protected HashMap<String, Object> attributes;
 }

public abstract class BDO implements BDOInterface {
    private String oid;
    private boolean deleted;
    private Date modificationTS;
    private transient boolean saving;
    private Date creationTS;
    private String modifiedBy;
}

public interface BDOInterface extends Serializable, DCG, C { ...}
public interface DCG { ... }

with this code the app was reading TC instances normally (all fields on their place). ObjectDB Doctor did not find on them any mistake.

Then I moved the interface C from parents of BDOInterface to parent of DCG and changeed nothing else: 

public interface BDOInterface extends Serializable, DCG { ...} 

public interface DCG extends C { ... }

After this change the app starts, it only reads the objects, no writing happens, but still the instances of TC become corrupted. It is visible also in the DB Explorer that the values of the fields are shifted, so in one database TC.tableID contains the value of BDO.modifiedBy, in other database TC.tableID contains the value of BDOWA.attributes converted to String (probably via the toString() method).

The DB Doctor finds then errors like this in the file:

ObjectDB Doctor [version 2.8.3_05]
Copyright (c) 2021, ObjectDB Software. All rights reserved.

Scanning the database file...
.................................................. 100MB
.................................................. 200MB
.................................................. 300MB
 300MB (total)
Analyzing database structure...
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Page Content Errors
-------------------
[1] Page #19753 entry 0 has unexpected field count (7 instead of 5)
0. oid => '567651'
1. deleted => false
2. modificationTS => 2021-04-16 13:38:57
3. creationTS => 2021-04-16 13:38:03
4. tableId => 'vanova'
5.  => null -> byte[1110]
6.  => 'SmartTablePreference -  - eu.extech.quant.analyzer.advanced_selection.RackCategorySelectorPanel$1'
  eu.extech.quant.TC(624):567651
[2] Page #33279 entry 1 has unexpected field count (7 instead of 5)
0. oid => '559770'
1. deleted => false
2. modificationTS => 2021-03-17 07:03:27
3. creationTS => 2021-03-17 07:02:33
4. tableId => 'vanova'
5.  => null -> byte[422]
6.  => 'SmartTablePreference -  - eu.extech.quant.dashboard.recent_items.RecentItemsPanel$3'
  eu.extech.quant.TC(624):559770

The value of field 4 "tableId" belongs to BDO.modifiedBy which is not even listed.

The value of field 6 belongs to tableId.

The field BDOWA.attributes is also missing in the list.

Neither ObjectDB log, nor the application log wrote any errors, so it looks to me that it is some failing schema evolution.

When I tried to fix the DB file, the Doctor deleted all listed instances of TC.

Could u please help me clarify how could this happen and how to avoid it ?

Since you are using version 2.8.3_05 it might be the critical schema bug (issue #2621) that was fixed in version 2.8.4. Please try to open the database (maybe the version before running the Doctor) with the last version of ObjectDB, for example, using the Explorer, and see if you still see the issue.

Version 2.8.5 did not help.

1. We tried to open a DB with already corrupted data (by the schema change, without fixing the DB file with Doctor) using ObjectDB 2.8.5 and the data was still corrupted.
2. We tried to update the ObjectDB to 2.8.5 and run our app with schema change on the DB which was not corrupted before and the corruption happened also.

Do you have some other idea ?

Thank you for the update.

It seems that to explore this issue further we will need a test case that demonstrates a failed schema upgrade.