In some way, something similar is happening already in Neo4j Spatial. There is the domain dataset that e.g. could be created using the JRuby or Spring Data bindings, using the one-node-per-object approach. For the exposure of Polygons, Layers, LinesStrings and Points onto a GIS view, there are the GeometryEncoders/Decoders that tell how to fish out the information our of the graph via traversals, so that I see them as a projection, backing a class with an arbitrary amount of traversal and subgraphs.
Being able to extend the projection model to include these "projected" use cases would make for a very cool generic mapping layer, I guess it could even do a decent work mapping different approaches onto the dame graph (like serving a JRuby binding and at the same time being compliant with Spring Data and some higher order mappings like Spatial constructs). Very cool. 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 Thu, Jan 20, 2011 at 12:49 AM, Michael Hunger <[email protected]> wrote: > 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 < >> [email protected]> 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 >>> [email protected] >>> https://lists.neo4j.org/mailman/listinfo/user >>> >> >> >> >> -- >> David Montag >> Neo Technology, www.neotechnology.com >> Cell: 650.556.4411 >> [email protected] >> _______________________________________________ >> Neo4j mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > spring-neo mailing list > [email protected] > https://lists.springsource.com/listmanager/listinfo/spring-neo > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
