Replacement of cuds objects with different neighbors. update/add

[pablo-de-andres]

In GitLab by @urbanmatthias on Aug 22, 2019, 13:59

Assume update or a recursive add causes a cuds object to be replaced.
Let's say new_cuds replaces old_cuds in the session of old_cuds.
There are multiple cases to consider.
Below are the cases and the current behaviour.

• new_cuds has parents, that weren't parents of old_cuds.

  • the parents are already stored in the session of old_cuds.
  • they are not already stored in the session of old_cuds.
    → Add refereces between new_cuds and the parents that are already in the session.
    → Delete references between new_cuds and parents that are not available.

• new_cuds has children, that weren't children of old_cuds.
  → add/update them recursively.

• A parent of old_cuds is no longer a parent of new_cuds.
  → Add a relationship between that parent and the new cuds.
  → Necessary because reference to wrapper-parent should not be deleted on update.

• A child of old_cuds is no longer a child of new_cuds.
  → Remove the relationship between child and new_cuds.

[pablo-de-andres]

In GitLab by @urbanmatthias on Oct 10, 2019, 08:19

@pablo-de-andres Since we want to be backwards compatible, we should probably mimic the behavior of osp v2.

What was the behavior in v2?

[pablo-de-andres]

In GitLab by @urbanmatthias on Oct 10, 2019, 08:19

changed title from Replacement of cuds objects with different neighbors. to Replacement of cuds objects with different neighbors.{+ update/add+}

[pablo-de-andres]

In GitLab by @urbanmatthias on Oct 10, 2019, 08:25

In update we should probably implement something similar to the update method of dict(), i.e. keep the old children. Add the new children. Update/Replace new children that are already there.

In that sense update should only be allowed to get a single cuds object, that has to have the same uuid as self. (Breaking backwards compatibility)

[pablo-de-andres]

In GitLab by @yoavnash on Oct 25, 2019, 13:41

removed milestone