Hi,

As I mentioned a while ago I am looking at using IndexedRelationship's
within my application.  The major thing that was missing for me to be able
to do this was IndexedRelationshipExpander being able to provide all the
relationships from the leaf end of indexed relationships through the the
root end.  So I have been working on getting that support in there.

However in writing this I have discovered a number of other issues that I
have also fixed, and at least one I am still working on.  Since I was right
into the extra support for expanding the relationships it is hard to break
out these fixes as a separate commit (which I think would be ideal), so it
will most likely all come in together hopefully later today (NZ time).

Just letting everyone know in case someone else is doing development against
indexed relationships.

Quick run down of the issues, note: N -- IR(X) --> {A,B} below means there
is a indexed relationship from N to A & B, of type X.

1) Exception thrown when more than one IR terminates at a given node, e.g.:
N1 -- IR(X) --> {A,B,C,D}
N2 -- IR(X) --> {A,X,Y,Z}
Will throw an exception when using the IndexedRelationshipExpander on either
N1, or N2.

2) Start / End nodes are transposed when the IR has an direction of
incoming, i.e. the IR is created against N but across a set of incoming
relationships:
N <-- IR(Y) -- {A,B,C}
Will return 3 relationships N --> A, N --> B, N --> C.

I have written tests for each of these, as well as a couple of other tests.

Still completing (1) and have a little question about this.  In order to fix
this I may need to introduce a unique ID stored against the IR both at the
root and at the leaves.  Currently the relationship type is used to name the
IR at both root and leaves, but in the case above that means you can't tell
from node A which KEY_VALUE relationship belongs to which IR tree without
traversing the tree.

So the question is adding this ID would mean that anyone who is already
using this wont have the ID, and therefore without care will be data
incompatible with the updated code.  This could be managed via a check for
the ID when accessing the tree and if it isn't there doing a walk over the
tree to populate all the places where it is required.

In general in developing against this code where do we sit on data
compatibility and API compatibility?

Cheers
Bryce
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to