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
