Layered entities

[rpx99]

I recently learned we have layered entities and as part of this concept a ready to use versioning layer.

Firstly, it looks like in case I use this on the dataroot object I can (in theory) create a complete versioned history of my object graph (something like a "temporal database") which sounds great, e.g. for timetravelling the data or simple datawarehousing within the application scope.

Still a few points I am confused about.

• From a concurrency perspective it seems not useful to have autoincrement as a versioning ID?
• I am not sure when I declare .addLayer(versionContext) on the datastore's root object if this is then a problem.
• Maybe for this special case (data root) it is then like a hibernate sequence in a database?
• Otherwise I think a decentralized and unique id approach using a UUID (takes more space) is more appropriate?

I don't understand fully what this warning means:

Do not share auto-incrementing contexts! Use a mutable context instead.

The documentation of layered entities talks about the logic layer and reads:

Logic, nestable in an arbitrary number of dynamically created logic layers, e.g. logging, locking, versioning, etc.

I think I understand the versioning aspect. For each entity creation there is an version with id 1 and then successively for each update (is this a store of an object in the object graph operation ?) there are appended copied versions with id 2, 3,...

Now I have different versions, but what about locking? There is synchronized keyword, Mutex Locking for Spring Boot or the new Feature Request: Adding Synchronization and Locks via AspectJ

What I am interested in is a way to do it in CDI / Jakarta EE. It should be possible to create a @Read / @Write annotation like in Sping Boot?

But, how does this add up to the layered entities? To prevent multiple users changing the same part of the object, e.g. a name, seems necessary.

Some questions about the generator:

• How to evolve the code created by defining entities from the maven plugin? It looks when I change something I need to re-run the whole creation?
• Are there any protected areas (for not generated code) possible - maybe sometimes a bit of customizing needs to be done, i.e. adding my own code additional to the generated stuff?
• Generation is great but the outcome, i.e. the number of generated classes and the amount of code can get really get quite big looking at even the quite small examples?
• Maybe it is better to handwrite it because a lot of the generated code may not be needed at all?

Comparing with the XDEV Spring-Data-Eclipse-Store (SDES): thinking in the eclipsestore object graph way - does the layered entities approach basically tries to solve the same problem as SDES does (but without the working copies)?

I am trying to understand a few concepts here related to concurrency, locking (pessimistic / optimistic) and versioning...

Is it possible to provide a more complete example addressing my questions?

The https://github.com/eclipse-store/store/tree/main/examples/layered-entities seems a bit too small to me, e.g. there are no Creator / Updator classes included and how is it used with the store?

Thanks.

[hrstoyanov]

Here is the reason for not sharing auto-incrementing using
#185 (comment)

The Entity framework is designed to be thread-safe by default, changing immutable data in one shot. Check out the generated Updaters and how a single field change cause entire immutable data object change.

If you need to control concurrency further, I think the team recently added to the Serializer sister project some of the ideas discussed here

In a way, the entity framework implements with code generations two upcoming/missing Java features:

• Java "withers" (JEP 468)
• Java concise method bodies (https://openjdk.org/jeps/8209434)