I find it really interesting that I am working on something on the similar lines for my own application, never thought it would make sense to anyone else :) Keep the spirit of free schema - yet enable people to work in a constraint defined by themselves for their particular domain. eg :
Person interstingPerson = someService.get(Person.class, some props... ); ........ Friend friend = interstingPerson.as(Friend.class); ... etc ... The classes would have subclasses generated. someService.get() would actually return the subclass. Any traversal you would want to do from say Person or Friend - would be defined in these classes as abstract methods. The concrete classes would be generated. Just an abstract of what I am doing for my application - please let me know if you think this something that makes sense for being shared. I can work on that part. Thanks Guru On Wed, Jan 19, 2011 at 5:10 PM, 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 > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
