I've just started experimenting with neo4j and spring data approach (I'm new here). But I find the multiple projection idea a very valuable one. Consider a very different approach to working with graph data I've been using so far (before neo4j). The shared graph data is stored in a triple-store (used by multiple apps). The data required by the application is queried by the app using sparql. The resulting rdf is bound to pojos using a JPA-like approach. While this method has many drawbacks, the primary benefit is that it allows for evolution of schema on the back-end (triple store). The apps can use a completely different data model - either by specifying it in sparql query or in the JPA binding. This is very different from the neo4j use-case, but we have found the flexibility of the lose binding to be a very "freeing" experience.
It would be great to see such a feat in neo4j. A On Wed, Jan 19, 2011 at 9:21 PM, Peter Neubauer <peter.neuba...@neotechnology.com> wrote: > Interesting. > Then, projections would in many aspects be like the persistence > counterpart of the Qi4j Mixinx or Scala Traits, not hijacking the > center of interest (object, node) but rather adding to it or giving it > type when needed and otherwise keeping out the the way ... > > 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://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. > > > > On Wed, Jan 19, 2011 at 9:13 PM, Andreas Kollegger > <andreas.kolleg...@neotechnology.com> wrote: >> That's an interesting observation David, about single nodes or not. It seems >> appealing to allow for a completely flexible mapping from any field to >> locations in a supported data store. That could be a later elaboration to >> fully embrace the idea of classes as projections. Initially, one node per >> projected class is probably confusing enough. >> >> For me, thinking about the class as a projections creates a consistent >> mental model that never feels like cheating. The "underlying node" is no >> longer looking underneath the covers, instead it's just another projection >> with graph-like semantics. Versioning, polymorphism, data-hiding, pivoting >> to an unrelated domain. As you say, David, it's all an interpretation. >> >> Though, I can certainly imagine use cases and business settings where such a >> perspective is abhorrent. >> >> -Andreas >> >> On Jan 19, 2011, at 7:50 PM, David Montag wrote: >> >>> Hi, >>> >>> I think that's a good idea. It makes good use of the schema-free nature of >>> the graph database, and also decouples the data from the interpretation of >>> the data. I'm not sure it has to be two different modes. Maybe you just use >>> one "projection" of the data if that's all you need. Or you use multiple. >>> >>> Does this still imply one node per class (projection)? Are you aiming to >>> change that too? >>> >>> David >>> >>> On Wed, Jan 19, 2011 at 3:40 AM, Michael Hunger < >>> michael.hun...@neotechnology.com> wrote: >>> >>>> Today Andreas Kollegger and I had an interesting discussion about the >>>> prevalence of class based mapping of entities to a graph store. >>>> >>>> One of the strengths of a graph store is that you don't need a strict >>>> schema for your data and you can use lots of different projections to work >>>> with it. >>>> >>>> Spring Data Graph currently focuses on a single projection of a node to an >>>> entity instance (1:1) that traditional ORMs focused on. >>>> >>>> But we could do more. We can project the node to many different classes, as >>>> long as the properties that are part of the class are there, we can >>>> sensibly >>>> work with the node. >>>> Even if the projection class is not part of the type hierarchy that was >>>> originally used to create and populate the node it can be used to access >>>> it. >>>> >>>> That makes room for some interesting things like: >>>> * new domain concepts can be used on top of existing data >>>> * get rid of inheritance hierarchies >>>> * traverse over a lot of nodes that support some basic properties that form >>>> a concept (e.g. Person) using that simple concept during the traversal and >>>> from there project those nodes to more concrete concepts as needed (e.g. >>>> Employee, Customer) >>>> * data/schema evolution / versioning >>>> >>>> We can run DATAGRAPH in a strict mode (not default) where it checks that >>>> the node requested always fit to the domain class specified (according to >>>> the type hierarchy stored in the graph). But we can (and should promote) >>>> running it in a more loosely >>>> coupled way where this free projection is possible. >>>> >>>> I would like to introduce a <T> T NodeBacked.projectTo(Class<T>) method to >>>> the aspect so that this projection is easily available. >>>> >>>> Looking for feedback on that. >>>> >>>> Cheers >>>> >>>> Michael >>>> _______________________________________________ >>>> Neo4j mailing list >>>> User@lists.neo4j.org >>>> https://lists.neo4j.org/mailman/listinfo/user >>>> >>> >>> >>> >>> -- >>> David Montag >>> Neo Technology, www.neotechnology.com >>> Cell: 650.556.4411 >>> david.mon...@neotechnology.com >>> _______________________________________________ >>> 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 > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
