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
