Yup, on this node, Andreas' JRuby at http://github.com/andreasronge/neo4j bindings are essentially treating the graph as a object databse. Every node is read up, its classname=..... property used to construct a class, and you can dynamically do whatever you would do witha normal JRuby object. I can imagine a few other nice wrappings turning Neo4j into a Object Persistence store.
However, ease-of-use comes at the cost of expensive deep traversals since that is essentially not happening in-graph but up and down the JRuby object layer. We are focusing on doing one thing good- graph traversal and storage. Just did a test on this - the speedup is about 10x, will write a blog post on it :) /peter neubauer COO and Sales, Neo Technology 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 - Relationships count. http://www.linkedprocess.org - Distributed computing on LinkedData scale On Sun, Nov 22, 2009 at 8:11 PM, Todd Stavish <[email protected]> wrote: > Plagiarizing the now defunct American anti-drug campaign, "Just say > no...to object features." The memory management and schema processing > of objects would decrease the speed (and arguably the elegance) of the > graph. > > > > On Sun, Nov 22, 2009 at 1:26 PM, Emil Eifrem <[email protected]> wrote: >> On Sun, Nov 22, 2009 at 18:34, Robert Lockhart <[email protected]> wrote: >>> it's super-lame that you only allow a basic set of objects to be the values >>> of properties. Any plans to open it up to arbitrary objects? >> >> No. We're not an object database. I think going down that path opens >> up a whole can of worms that I'd rather not get us into. For example, >> class/object versioning and activation depth. >> >> On the contrary, I've always agreed with the relational gurus that >> separating data and logic is a good thing. I.e., a programming >> language paradigm is not necessarily the most robust and effective >> data model. I disagree with the RDBMS guys, however, that tables is >> that data model. At least not for the majority of the applications in >> 2009. >> >> Anyway, it seems to be easy enough to map any object down to the >> property data types Neo4j provides. If you think about it, you can >> recursively decompose most Java object's state to Strings + the JVM >> primitive types. What we need to add is more powerful wiring so you >> won't have to do as much of the get/setProperty that you need to do >> today. >> >> Cheers, >> >> -- >> Emil Eifrém, CEO [[email protected]] >> Neo Technology, www.neotechnology.com >> Cell: +46 733 462 271 | US: 206 403 8808 >> http://blogs.neotechnology.com/emil >> http://twitter.com/emileifrem >> _______________________________________________ >> Neo mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user >> > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
