Fast Object Database for Java - with JPA/JDO support

IDs of Entities suddenly became UUIDs?



We're having our system with ObjectDB 2.4.5 in production since this year April and it works just fine.

However, now we've discovered that suddenly partial Objects in some DBs in production do have a UUID String as their id instead of Long which is of course causing a lot of troubles. Note that this even occurrs on the same "Table" -- some saved Entitities of same type do still have a Long ID, others a String UUID.

Our Base-Entity everything inherits from is declared as usual with Long:


private Long myId;

This has always been working, however, suddenly partial Objects in the DB are having the field "myId" as type "String" and with an UUID!?? How could that have happened and what are we supposed to do now to fix this as when quering those entities they always have a myId of zero!?

We are NOT manipulating the id manually in any way so I don't have a clue how that was caused





As we do have this issue in a running production system I'd really prefer a timely reply on this one.

After further investigation I've discovered that all Databases we use are affected by this. Many of them having mixed Long and UUID String ids in the same entity type!??



As discussed on this issue, ObjectDB doesn't support auto generation of uuid. We double checked now (following your report) and we cannot find anything in the ObjectDB code that can generate uuid values.

Therefore, uuid values are probably generated by your application.

Please check that you have only one version of every entity class, since that problem may be caused by having different versions of the same entity class (e.g. one with myId as Long and the other with myId as String). Also check your code for generating uuid strings.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Actually, we're only having one version of our entities for sure which are using a Long id.

Anyway, as our databases are polluted now with partial UUID and partial Long, would it be safe to "simply" switch the type of our Entitie's IDs to String, generate UUIDs ourself for new entities and be done with it thus using the current databases without problems?


It is not that simple. For example, changing IDs may affect other objects that reference these objects. If we can get access to the database maybe we can try understanding this strange situation.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Can we, the public, know what is the status of this problem?

It seems to be very important. I'm considering ObjectDB for a large-scale project, therefore I'm very interested.


Maybe quasado can provide up to date information about this problem.

Possibly there was a schema change that included @Id fields. This situation of mixed ID types can be easily reproduced by persisting objects with one @Id type, and then persisting other objects (of the same entity class) with a different @Id type. For example, adding a new @Id field to an entity class can hide another existing @Id field higher in the hierarchy, and cause mixed primary key types.

As noted above, ObjectDB never generates UUID values, so obviously these UUID values had to be generated by the application, and possibly set into a field that was marked (maybe by mistake) as @Id.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Post Reply