It was you David, who asked for the stricter checking against the type hierarchy stored in the graph :)
It does imply (right now) one node per class but not one class per node. As this one node gives the instance its identity. It is also very similar to the Qi4j state mixins where the id was the only fixed thing around. But the thought that we started with the cross-store could apply here as well, as long we have an id (and perhaps an id-store-mapping) we can also have multiple stores contributing to the current projection. Cheers Michael Am 19.01.2011 um 19:50 schrieb David Montag: > 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
