[Neo4j] Spring Data Neo4j 2.0 Roadmap
jpbergamin at gmail.com
Thu Oct 6 15:03:33 CEST 2011
> One way of handling different types of "use-cases" per node is to use projection. So per context you have different types with attributes and behaviour that is just relevant for the context.
I have to admit that I never worked with projection so far. The
problem with the projection approach is IMHO the fact that I normally
cannot project an entity to another type because I don't know the end
type. When as in our example a traversal follows all HAS_FLOW_TO
relationships (Service 1 --> Device 1 --> Service 2), all visited
nodes are of some common base type/interface. The actual type is not
known in advance and the actually visited node therefore cannot be
projected to the concrete (unknown) type. This of course can be
overcome by using instanceof constructs, but as an OO disciple you
won't dare... :-)
> Regarding your use of interfaces, of course we could support using interfaces as target types for relationships and start/end nodes, implementation wise it would either be dynamic proxies, cglib or some AJ magic.
> The only issue I see here is that besides getters/setters for the attributes you would also want to have actual implementation / behaviour that would have been implemented somewhere (and then delegated to). E.g. in a inner class of the interface which is then initialized with the concrete instance of the node-backed interface(s) implementations. Had some interesting discussions with Oliver Gierke from VMware how one could use generics and the "&" operator to define interface mixin composition. But the interface stuff won't be in there for 2.0.
We currently have the common implementation for all our entities in a
static utility class (ouch). The entity classes itself (e.g. class
Device) implement all methods from all interfaces itself, but delegate
to the utility class, passing "this" as an argument to the methods.
NodeBacked methods like "relateTo" are then executing on that "this"
reference. Not very comfortable, but it's something we at least can
share common implementation.
> Regarding Nodebacked - as the core changed to work on just annotated entities without any AJ I changed the target type of almost all operations to be just "Object", It could be that some of the methods would benefit from generics, didn't look through that.
> Regarding your editor/POJO - that would be solved by the fetch/load strategy on load or detach and by the save operation. Those entities should then also be serializable so that they are no longer actively connected in the graph.
That's great news. So we hope to get rid of our in-memory implementations again.
> A question - is your meta-model also stored in the graph? If you there could be interesting relationships between elements of the model and meta-model to be explored.
No. Our Meta-Model is not stored anywhere, but in code. But I really
would like to see the definition of such a meta model "somewhere".
> Regarding the specification of subgraph models. I agree a interface based approach would be interesting. OTOH having a DSL for defining those subgraphs would probably be even more compelling. After all you should be able to transform the one into the other and vice versa. That's something where .net's LINQ and the dynamic types derived from such a query shine.
> For "dynamic" content you would have (as you did) either implement field-acessors to store them fine grained in the graph for further processing or just provide a Spring Converter that converts your documents into json structures which would be stored as strings. There are plans to support such structures natively in Neo4j but no definitive planning for those features.
> Regarding the traversals and converting entity path, there is a Evaluator that provides you with an EntityPath. But your're right, the GDC should be passed in, can you create a JIRA item for that?
Please see DATAGRAPH-116
> I tried to document all the user facing parts of the API, so if there's something missing please let me know. You can also ping me on skype.
> Regarding loading stragegies. #1 and #2 will be there, for the others there won't be enough time before SpringOne. I also like #6, probably with the interface base graph definition it will be less effort to define them.
Having #1 and #2 with POJOs already would be beneficial for us.
More information about the User