Issue #2635: boolean field flips after schema update (in class) of another field

We have added a boolean field to a class with default value false. After deployment on several instances the values of other boolean fields in the same class (next to the new one) flip or change. This is a serious issue because the related fields were not touched (no change of name or anything) and values in the database changed. We did not have this in our testing and stating environment, but now in field. Object DB version was upgraded maybe two times in the last months in the field and is currently 2.8.3.

This could be related to issue #2621, if this class had many previous schema evolution changes (you might have a longer history of schema changes in deployment databases than in your test databases).

Note that if what you see is due to that issue, the problem is with queries rather than with the real content in the database. Therefore, the database is not changed until the object is stored again after such a query.

The best move could be to try version 2.8.4 that fixed that issue.

I think the schema may changed 2-5 times during the last months and not more. Also in production. Can it still be this issue?

We also do not have an Exception in the query. We catch all of them.

The schema is as followed. We added "test" field and "instruction" and/or other values changed. But not all values changed and also not all values were set to the default value. Some remained "true" as set before.

@Entity

public class Configuration {


@Id @GeneratedValue

private long id;


@Embedded

private Application application = null;


@Embeddable

public static class Application {

private boolean instruction = false;

private boolean registration = false;

private boolean profile = false;

private boolean test = false;


...

It is usually difficult to know the total number of schema versions of a class, as sometimes users start deployment with a database that was previously used in development.

If this is a database that you can share with us we can check it.

We have embedded devices and they start with a new database. Only we do schema changes very very very rarely. I am 100% sure about every schema change and they must have been between 1-5 maximum. However, we maybe updated the ObjectDB version once or twice.

That mentioned issue does not necessarily causes exceptions, but if you are sure about the number of schema evolutions then it reduces the likelihood that the issue is related. Anyway, an upgrade to 2.8.4 may still be the best option to try now.

I would recommend to write a test case for this scenario. We currently cannot reproduce in development environment. But it occurred for sure!

More details are needed in order to write a test case that can catch such an issue. We already have tests that check that schema evolution work, including when fields of all types are added, and every build of ObjectDB is released only after passing these tests.

If you see that issue again with version 2.8.4 please report.

Note that another reason for generating many schemas (and problems in general), is when the database is accessed by two versions of the class alternately (e.g. users use the old and the new software with the same database). Every such access can cause another schema change.

Any updates regarding this issue? Did it happen again? Have you switched to version 2.8.4?

What shall I say. This is a layer not under our control and hard for us to reproduce or write tests for. It has happened several times - this is something which should never happen for a database. We don't really know if it is fixed in 2.8.4, as we cannot reproduce in development or testing environment.

Thank you for the update. No argue that it should never happen. Anyway, if there are no records of it happening with version 2.8.4 yet then it may be a good sign. Meanwhile there are no similar reports from any other user, and hopefully this is the rare issue related to schema evolution that was fixed in version 2.8.4.