NeoDatis ODB

1) I Agree that NeoDatis ODB should provide Delete Cascade behavior. But I
see itas an optional behavior that the user can opt for.

2) Cyclic references

Garbage collector implemented with only the reference counter can't manage
cyclic reference. But, I think it would be a bit different here. While i
was thinking about this problem, I started to think how traditional
relational database manage cyclic references. I think they don't: if you
want do delete a cyclic reference in Relational database, you have to
manually update one side of the relation to null and then execute the
delete. Or I am wrong? So I think it could be like this with ODB too.

Here is my understanding of the concept of ROOT: if an object have been
persisted directly, it is because it has its 'own life'. If an object has
been persisted for being referenced by another one, it means it is not that
important and that its 'life' depends on its holder (the root object that
actually references it). So deleting the Root object should delete the
referenced object (if reference counter is 0).

The point is that I am not sure that this is the generic behavior. Here,
we would assume that developers will always call the persist method
directly for theses 'important objects'. What if they don't (like already
happened with me)?

Is it correct to have the delete behavior depending on the way the object
has been stored?

Object Reference Integrity versus Memory Garbage Collection : Garbage
Collection have to eliminate all the orphans (objects that are no more
referenced) from the memory and only keep active references. Can we apply
that to Object Databases?

The idea behind a 'Root' flag is to allow certain objects to be persisted
in the database even if they are not referenced from other objects in the
database.
Other objects, that are not 'Root' should only be persisted if they can be
reached via direct or indirect references from 'Root' objects, so that
reference integrity is achieved.
Deleting an object will not result in disposing it, unless it has no more
references.

This is very similar to the memory management in Java: objects are
available if they are referenced from a set of 'Root references', and all
other objects are Garbage Collected.

My problem is that since NeoDatis ODB provides cascade persist by default
it <<should>> provide cascade delete.
However cascade deletion WILL break the database contents UNLESS Reference
Integrity is implemented.

There is no need to implement Garbage Collection to be able to support
Reference Integrity.

However there is a more-pressing issue, which I detected while thinking
the idea over: circular references.

Reference Integrity will impose restrictions on deletion, and hence the
problem: how to delete two objects that refer each other. Deleting either
will be vetoed by RI, unless ALL the objects in a circular graph are
deleted simultaneously.

So here comes the 'Root' flag in action: deleting an object will drop the
'Root' flag, and if the object is no longer referenced from another 'Root'
it will be disposed, possibly cascading to other objects that are also not
referenced from other 'Root's.

I believe the 'Strategy 1' that is proposed will not work if the database
contains circular references, unless some modification is devised. I am
currently experiencing this situation, and this is not an unusual case, as
there is no Bidirectional Reference in OOP.

We can start implementing the strategy 1 of
(http://wiki.neodatis.org/object-reference-integrity) or a modified version
of this strategy suggested by Lachezar.

Lachezar suggested to use the reference counter and a flag for root
objects. We talked about it on jabber.

Lachezar, after re-reading our talk, I understand how the 'Root' flag
works but I can't see the benefit of it against using just a reference
counter. And the fact to set Delete cascade as default behavior for delete
does not seem to be the best solution for me. Could you re-explain what we
gain with the Root flag & Reference Counter instead of only using the
reference Counter?