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
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
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
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
I've just started experimenting with neo4j and spring data approach
(I'm new here).
But I find the multiple projection idea a very valuable one.
Consider a very different approach to working with graph data I've
been using so far (before neo4j).
The shared graph data is stored in a triple-store
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
6 matches
Mail list logo
