[Solved] Persisting changes in Lists (missing documentation?)

[bachlge]

Documentation and Github example do not describe how Lists are to be stored as part of an entity.

Assume this data Model for representing a M:N relationship with additional data. Let's say the Relation Object is needed to store whether it is an own child or an adopted one:

Person ----< Relation >---- Person
       1   n          n   1

Person
------
id
name
parents
children


Relation
--------
parent_id
child_id
adopted

Assume a Parent-Person already has a List of Child-Relations.
Now add another Child Relation (the new Child is a Person Object which is already stored): the Relation Object is created and it is added to the List of Child-Relations of the Parent-Person and to the List of Parent-Relations of the Child-Person.

Application side of the data model works well: Parent Person is linked to all the Children, including the new one, all Children relate to the Parent-Person.
Just after a restart of the application, it is gone.

What needs to be stored?
[ ] the Parent-Person
[ ] the Child-Person
[ ] the Parent-Person's list of children
[ ] the Child-Person's list of parents
[ ] the Gigamap of Persons?
[ ] the Relation Object (which is not a direct part of the root)

and does the sequence of the update matter?
storageManager.storeAll(gigaMap, parent, child, child.getParents(), parent.getChildren(), relation);
or rather
storageManager.storeAll(relation, child.getParents(), parent.getChildren(), parent, child, gigaMap);

All these did not help to resolve my issue:
https://docs.eclipsestore.io/manual/storage/storing-data/index.html#_storing_modified_objects
https://docs.eclipsestore.io/manual/gigamap/crud.html#_removing_and_updating_entities
https://docs.eclipsestore.io/manual/gigamap/persistence.html

[hg-ms]

When adding an element to a list you need to store the list as the list is modified.

In your example this would be:
storageManager.storeAll(child.getParents(), parent.getChildren());
as you modified two lists.

The new Relation-Object will be stored too as it is recognized as “not yet stored” when storing the lists (see lazy storing).

One pitfall can be the initial state of a list. E.g. if you create and store a Person-Object with the parents and children lists being ‘null’ you need to store (update the persisted state) that object again after setting those lists to ´non-null´.

[bachlge]

thank you! now this is clear.

let me think loudly:

When an attribute of the Relation is changed, eg the begin-date, I only store the relation itself storageManager.storeAll(relation); although it is contained in the object graph only by references of other entity object to it?

And when a Relation is to be removed by parent.getChildren().remove(relation); and child.getParents().remove(relation); then again only storageManager.storeAll(child.getParents(), parent.getChildren());?

[hg-ms]

When an attribute of the Relation is changed, eg the begin-date, I only store the relation itself storageManager.storeAll(relation); although it is contained in the object graph only by references of other entity object to it?

Yes, if you modify a field you need to store the object the field belongs to.

And when a Relation is to be removed by parent.getChildren().remove(relation); and child.getParents().remove(relation); then again only storageManager.storeAll(child.getParents(), parent.getChildren());?

Yes, this is how deletion works. Remove all references to an object instance and store the modified objects.