Bryce, yes, that would be good to set up the code standard. Anders, do you know if that is still the latest version? I will check tomorrow.
Also, please send in your CLA according to http://wiki.neo4j.org/content/About_Contributor_License_Agreement so we can pull your contributions! Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://startupbootcamp.org/ - Öresund - Innovation happens HERE. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Mon, Sep 5, 2011 at 11:46 PM, Bryce <[email protected]> wrote: > 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 <[email protected]> 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 < > [email protected] > > > 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: [email protected] > >> > To: [email protected] > >> > 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 > >> > [email protected] > >> > https://lists.neo4j.org/mailman/listinfo/user > >> > >> _______________________________________________ > >> Neo4j mailing list > >> [email protected] > >> https://lists.neo4j.org/mailman/listinfo/user > >> > > > > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
