Great work Bryce,
I do have a question though.
What is the rationale for the restriction mentioned under "1)". Do you need
this for the general case (to make IndexedRelationshipExpander work correctly),
or do you need it for your own application to throw that exception? If the
latter is the case, I think it would be important to tease out the general case
and offer this new behaviour as an option.
A unique key for the index is a good idea anyway and can be added to
SortedTree. Generate a UUID and store it in two long properties. That way the
two values will always be read in the first fetch of the underlying
PropertyContainer. A getId method on the TreeNodes can then return a String
representation of of the two long values.
IndexRelationships are a relatively new development, so I think you are one of
the first to actually try it out. Personally I have chosen to directly work
with SortedTree, because I am working within the framework of a wrapper API, so
I can integrate the functionality behind the regular createRelationshipTo and
getRelationships methods.
I don't think API changes will be an issue at the moment.
Niels
> Date: Thu, 8 Sep 2011 10:22:11 +1200
> From: bryc...@gmail.com
> To: user@lists.neo4j.org
> Subject: [Neo4j] Issues with IndexedRelationship
>
> 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
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
