Interesting discussion. As a definite user of the reference node, I would hate to see it go. How about this, using the last idea of Emil's with named reference nodes from getReferenceNode(), but still support the old getReferenceNode() as a case with a default name. We support old code (except for people using getNodeById(0), of course), and we move forward to a more generic system, giving those of us that like having a root to start with what we want. The idea of multiple named roots seems more generic and flexible, and covers also the lazy creation concept. As Emil stated it is a bit like having a default index for finding starting points, instead of having a hard-coded starting point.
However, when put to the vote, I would probably just vote to leave it as it is because it works fine for me. I also kind-of think of the difference between one hard-coded root versus multiple configurable roots seems analogous to the unix '/' versus NT's multiple drives. Somehow the former seems simpler and more intuitive to me. The pros of a single reference node are that database users are more likely to be able to find and see all graphs in the database (should they wish), while multiple roots (or some other way of finding graphs) sort-of hides graphs (you need to know how to find them). This reduced transparency works against something I like to do, which is just browse the graph to see what is there. Perhaps having a getReferenceNodes() method to iterate over all is a way to allow browsers to find everything there is would solve this. On Tue, Dec 14, 2010 at 4:18 PM, Rick Bullotta < rick.bullo...@burningskysoftware.com> wrote: > Making it lazily created seems the best approach, which won't break > existing > apps nor affect those apps that don't use it. > > > -----Original Message----- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] > On > Behalf Of Emil Eifrem > Sent: Tuesday, December 14, 2010 9:56 AM > To: Neo4j user discussions > Subject: [SPAM] Re: [Neo4j] Reference node pains. > > Gang -- > > I've found that this is (as so frequently the case) a question of > different types of stakeholders. > > * For folks that are getting into Neo4j from a more graph > theoretical / algorithmic angle (for example, they might have found us > through Gremlin and Tinkerpop) then the reference node is a bug, an > odd escalated artifact that makes our graph less graph-y. [These are > also the folks who think nodes are connected by *edges* or arcs, > because that's how graph literature talks about it.] > > * For folks that are getting into Neo4j from a more industrial / > software engineering angle (for example by hearing a talk at a > conference like JavaOne) then the reference node is an intuitive and > pragmatic way of attaching various subgraphs to an entry point into > the graph. [These are also the folks who think nodes are connected > through *relationships*, because in normal lingo you say "there's a > relationship between these two entities."] > > Couple of options forward: > > (a) Keep it as it is. Pro with this is that it's worked and > provided value in real systems forever. Con is that it's unintuitive > and awkward for a segment of our user base. > > (b) Completely remove it. Pro with this is that it makes more sense > to one user group. Con is that we will have to replace it with > something that is as convenient (or more) as the reference node for > the users who *do* use it. > > (c) Create the reference node lazily on invocation of > getReferenceNode(). Pro with this is that we can cater to both use > cases -- if you don't like the reference node, just don't invoke > getReferenceNode(). Con is that it's non-intuitive: we do a mutating > operation as part of an API that advertises itself through its name as > read-only. > > (d) Codify the subreference pattern that we use so frequently, by > supporting named subreference nodes, a'la getReferenceNode( "actors" > ). Pro with this is that we have more powerful and explicit support > for a pattern that has emerged as a defacto way of using Neo4j. Con is > that it really is a special case of indexing and possibly of the > metamodel as well. > > I'm not sure which approach is the better one but I do think we should > address it once and for all and put this discussion to rest. > > Cheers, > > -EE > > On Tue, Dec 14, 2010 at 14:50, Rick Otten <rot...@windfish.net> wrote: > > I vote for it being optional. > > > >> Hi Marko, > >> > >> On Fri, Dec 10, 2010 at 7:35 PM, Marko Rodriguez <okramma...@gmail.com> > >> wrote: > >>> Hello. > >>> > >>> I have one question and a comment: > >>> > >>> QUESTION: Is the reference node always id 0 on a newly created graph? > >> > >> Yes. > >> > >>> > >>> COMMENT: By chance, will you guys remove the concept of a reference > node > >>> into the future. I've noticed this to be a pain in the side for people > >>> moving between various graph systems. Going from Neo4j to iGraph to > >>> TinkerPop to etc. The reference node, if the user is not conscious, > >>> begins to build as data is migrated into and from Neo4j graphs. And > what > >>> ensues is a data bug. Perhaps a GraphDatabaseServer = new > >>> GraphDatabaseService(String directory, boolean createReferenceNode). > >>> ...? > >> > >> The reference node is very helpful in certain use-cases. The current > >> implementation could however be improved. > >> > >> Would having the option to create a graph without the reference node > >> solve the problems you are experiencing? > >> > >> -Johan > >> > >>> > >>> Thanks, > >>> Marko. > >>> > >>> http://markorodriguez.com > >>> http://tinkerpop.com > >>> > >> _______________________________________________ > >> Neo4j mailing list > >> User@lists.neo4j.org > >> https://lists.neo4j.org/mailman/listinfo/user > >> > > > > > > -- > > Rick Otten > > rot...@windfish.net > > O=='=+ > > > > > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > -- > Emil Eifrém, CEO [e...@neotechnology.com] > Neo Technology, www.neotechnology.com > Cell: +46 733 462 271 | US: 206 403 8808 > http://blogs.neotechnology.com/emil > http://twitter.com/emileifrem > _______________________________________________ > 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
