On Tue, Dec 7, 2010 at 3:09 PM, Andreas Ronge <andreas.ro...@gmail.com> wrote: > An Node#isDeleted() method would also be fine.
The way I see it, there are two concerns here. The first is focused at the lower levels, where the WriteTransaction/LockReleaser discover an illegal operation - deletion of an already deleted primitive. This is a hard error and at their level it should throw an exception and of course set the tx to rollback only. This is mainly an engineering decision. The second is the user level where either the same logic should apply or a check should be made first to make sure things don't go downhill. Obviously the current approach is the former. Having just a isDeleted() method is kind of awkward because it would litter the code with if statements and things would be even worse with (checked) exceptions. Maybe stealing a bit off the id would be a better solution and have the NodeImpl/NodeProxy objects do the check internally. BTW, I think that from a user perspective with the current kernel such a wrapper object (with a boolean field possibly) would be the best approach, minimizing the bookkeeping in "business logic" code. What I find more interesting to discuss are the semantics of operations on primitives. At the moment there is no standard to adhere to and in that respect there is a decision to be made. What I mean is: what is the proper thing to do, conceptually, when doing basic primitive manipulations. Since there is an effort to standardize a graph traversal algebra, a similar thing should be done on a data definition level, with rationalization and detailed description of what is the Right Thing (TM) to do when, for instance, one deletes a Node from a graph, regardless of implementation. Obviously my thinking is influenced from the relational model, where there are hard constraints on different things - primary keys are an obvious example here. In that case, the proper thing to do was to make it propagate a hard error all the way up and all implementations do exactly that. In this way, behavior is standardized for all common operations. Should graph databases, beginning with Neo, undergo a similar process? Such an effort would give definite answers to most such problems, for example the "forced"/cascading deletion issue mentioned before. On the other hand, maybe I am overthinking this. cheers, CG _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
