Just noticed that after my changes were pulled into the main git repo that
they don't quite fit in with the formatting of the original code (original
is using tab characters and my IDE is setup to use 4 spaces).

Which led me to finding this: http://wiki.neo4j.org/content/Coding_Standard

I am assuming that this is still the standard?  I will setup my IDE for when
working on this code as per this standard and next time I do some changes
will first do a reformat code + commit.

On Tue, Sep 6, 2011 at 9:31 AM, Bryce <bryc...@gmail.com> wrote:

> Hi Niels,
>
> Thanks for your feedback below.
>
> Specifically on the anonymous inner class issue in general they can be used
> as a Comparator without a problem, and in this case it worked perfectly for
> creating the IndexedRelationship.  The issue was when then trying to
> instantiate the anonymous inner class in IndexedRelationshipExpander which
> was throwing a ClassNotFoundException (I think, from memory).
>
> I also think non-static inner classes also wouldn't work as it is coded
> right now, since they need a reference to the outer class, and personally
> supporting them may be rather difficult.
>
> Even if anonymous inner classes could be supported, is it really a good
> idea to store as a comparator XYZClass$5 when adding another anonymous inner
> class to the XYZClass would increment the number and mean the index will no
> longer work.
>
> Given what you have said about how the tree is represented it should be
> relatively easy to have IndexedRelationshipExpander support following
> relationships from the leaf nodes through to the root (as well as what it
> presently does: root -> leaf & direct relationships).  I might have a look
> at doing that later on today.
>
> Cheers
> Bryce
>
>
> On Tue, Sep 6, 2011 at 6:58 AM, Niels Hoogeveen <pd_aficion...@hotmail.com
> > wrote:
>
>>
>> Hi Bryce,
>> Sorry for my belated response. I have been away for a couple of days and
>> wasn't able to check my emails.
>> I am glad you took the time to look into the IndexRelationship module. It
>> certainly could use some scrutiny.
>> Remarks:
>> 1)  Good catch... Something the unit test didn't catch because it runs in
>> the same namespace as IndexedRelationship itself. Didn't catch it in user
>> code either, because personally I prefer to directly call SortedTree.
>> 2) Agreed. It should be possible to define more than one IndexRelationship
>> per node.
>> 3) I haven't tried out an anonymous inner class as Comparator. As far as I
>> can tell any object implementing Comparator<Node> should be able to work as
>> a comparator.
>>
>> Questions:
>> 1) That is certainly an option. IndexRelationships however offer you the
>> possibility to sort your Relationships based on some value associated with a
>> node (for example creation/edit date of the document). This may be a reason
>> to use IndexRelationships even in the situation where you have less than 500
>> entries per tag (though it would be possible to do that sorting in memory
>> too).
>> 2) The end node of an IndexRelationship is always referred to by a
>> Relationship with RelationshipType "KEY_VALUE", and has a property
>> "tree_name" (both are defined in SortedTree). The "tree_name" property has
>> the same value as the RelationshipType.name used in IndexRelationship. To
>> traverse from a leaf node to the tree root, keep following the incoming
>> relationships: KEY_VALUE (there is only one), KEY_ENTRY (there can be many),
>> SUB_TREE (there can be many), TREE_ROOT (there is only one)
>> Niels
>>
>>
>> > Date: Fri, 2 Sep 2011 11:44:40 +1200
>> > From: bryc...@gmail.com
>> > To: user@lists.neo4j.org
>> > Subject: [Neo4j] IndexedRelationship some observations and questions
>> >
>> > Hi,
>> >
>> > I have been looking at performance options for Neo4j as presently I have
>> > been observing a number of performance issues.  I am still investigating
>> the
>> > way to get the best performance out of what I am doing, and one thing it
>> > might be are longer running transactions stopping other work going on
>> (but
>> > thats an aside to what this message is about).
>> >
>> > One of the things that I investigated using was the IndexedRelationship
>> work
>> > by Niels.  Thought I would give a bit of feedback, although I haven't
>> quite
>> > got this implemented at present.
>> >
>> > 1) I had to change the IndexedRelationshipExpander to be a public class
>> in
>> > order to use it outside the package its in.
>> >
>> > 2) IndexedRelationship assumes only one tree root per node, whereas the
>> > expander allows for multiple (IndexedRelationship uses
>> getSingleRelationship
>> > vs expander using getRelationships then matching on tree name).  Having
>> > multiple would obviously be good as it means you could have two types of
>> > relationships covered by IndexedRelationship's.
>> >
>> > 3) Might pay to make it clear in the Javadocs for IndexedRelationship
>> that
>> > the comparator can't be an anonymous inner class.
>> >
>> > Then I have some questions about usage of this.  First a little
>> background
>> > of the model I have, from reading a few things it seems quite standard.
>> >  There are a lot of "document" nodes each of which have a relationship
>> with
>> > multiple "tag" nodes.  Documents generally have in the order of 10-20
>> tags,
>> > and tags can have as few as 1 document and sometimes tens of thousands.
>> >  When tags are viewed through the UI they are almost always displayed
>> with a
>> > descending date ordered list of documents.  Seemed to be to fit quite
>> well
>> > with IndexedRelationship.
>> >
>> > 1) I was thinking of having a switch over point at say around 500
>> documents
>> > for a given node where I will switch from using normal relationships to
>> an
>> > IndexedRelationship as I was thinking at small numbers of relationships
>> > normal relationships would be quicker.  Would that be correct, or not
>> worth
>> > it?
>> >
>> > 2) On the tag end (which is the incoming end of the document-tag
>> > relationship) I was going to use a IndexedRelationshipExpander which
>> would
>> > cover the case of whether the relationship was done through normal
>> > relationships, or through an IndexedRelationship.  I also need to get a
>> set
>> > of tags from the document end where their may be both normal
>> relationships,
>> > and relationships coming from multiple IndexedRelationship's.  From
>> looking
>> > at it IndexedRelationshipExpander doesn't cover the reverse direction,
>> but I
>> > would imagine using a relationship expander here would be correct.  What
>> > would the best way of doing this be?
>> >
>> > As an aside it may be a good idea to note in the configuration settings
>> > page:
>> >
>> http://wiki.neo4j.org/content/Configuration_Settings#Optimizing_for_traversals_example
>> > that -XX:+UseNUMA
>> > only works when using the Parallel Scavenger garbage collector (default
>> > or -XX:+UseParallelGC) not the concurrent mark and sweep one.  Based on
>> >
>> > 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
>>
>
>
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to