-
-
Notifications
You must be signed in to change notification settings - Fork 874
Closed
Description
OrientDB Version: 2.2.35
Java Version: 8
OS: Windows, Linux
Expected behavior
A model where an entity is related to another entity by a one-to-many relationship implemented using a Set.
Scenario:
- fooEntity is created.
- barEntity is created.
- barEntity is added to fooEntity.
- fooEntity is saved.
- An entity retrievedFoo is retrieved from the database using fooEntity.id
- A property is set in retrievedBar (acessed via retrievedFoo). Both entity handlers are now dirty.
- retrievedFoo is saved.
Actual behavior
If the first save and the latter retrieve/save are executed using different connections (typical scenario in a multi thread application) the save operation is not propagated, and retrievedBar stays marked as dirty.
Steps to reproduce
I've created an integration test reproducing it.
PropagateSaveOnSetFieldIT
3 scenarios:
- Master entity saved using a connection and later changes saved using the same connection. It works.
- Master entity saved using a connection and later changes saved using a different connection. It fails.
- same scenario than the former but the relationship is stored using a List instead of a Set. It works.
Something I have noticed while debugging is that when a single connection is used, when retrieved, the aggregate root's internal dirtyManager is not null (actually the root and the child share the same dirtyManager). In the scenario using different connections, when retrieved, the dirtyManager in the root entity is null.
Metadata
Metadata
Assignees
Labels
buglegacy not used anymorelegacy not used anymore