Cedric, thanks so much for your feedback.
By now I kept the template and the NodeBacked kind of separate. The Neo4jTemplate API has changed a bit :) see here: https://github.com/SpringSource/spring-data-graph/blob/master/spring-data-neo4j/src/main/java/org/springframework/data/graph/neo4j/template/Neo4jOperations.java You'd be right to expect support for the NodeBacked entities in the template as well. Or at least create a separate template (or rather a repository) that is pre-configured to support a certain kind of NodeBacked instances, so its methods would automatically return instances of that nodebacked-instance. It would be interesting though how to handle that with the paths. Because in the path you can't statically reason about the type of the nodebacked and relationshipbacked that is contained in the full path. So although with the help of the node-type strategy (if one is set) we could figure out a NodeBacked type and return instances of that one, you as an user wouldn't get any compile time support for that. (Except if we were able to configure the Path with the types of the NodeBacked that we expect in there (for all paths) which is tricky if you take the dynamic nature of the graph into account. Something that could be more feasible is to use the projectTo facilities to have the NodeBacked/RelationshipBacked within a path be set to a common superset of the ones expected in there (e.g. Named) and then during the processing of the path project them to the concrete type that you want it to be used as. So I'll think about an "GraphEntityPath" and which constraints it would have to ensure. Regarding your traversal builder as you're passed the field on build() you can get the Annotation and from it the target class and then use an Evaluator which gets the type node via the INSTANCE_OF relationship and if that fits the type from the annotation then use INCLUDE_AND_CONTINUE and otherwise EXCLUDE_AND_PRUNE. (or EXCLUDE_AND_CONTINUE if you want to follow the path and not stop here). We could provide such an evaluator out of the box, that would actually be a good thing to have. That would then be a GraphEntityEvaluator that doesn't get a path but a GraphEntityPath. Really great ideas. Will try to do something around this for M4 :) Cheers Michael Am 23.02.2011 um 23:10 schrieb cedric.hurst: > > Firstly, thanks for your great work on the Spring Data Graph API so far. I > took a look at the draft you had out here: > > https://gist.github.com/835408 > > And it looks like an awesome start. I'm relatively new to Neo4J (saw the > SpringOne keynote and the roo talk), but one thing I think would be very > useful is if there was some sort of higher-level PathMapper that worked at > the GraphBacked level, instead of working at the Neo4j node level. > > In my immediate case, I have three NodeBacked types in my graph: TypeA, > TypeB, and TypeC. Types B and C can be related to Type A through the same > relationship type, but I want to define two traversals that include only > each type respectively. I'm using the FieldTraversalDescriptionBuilder but > its falling down when I try to do something like the following: > > class TypeA { > @GraphTraversal(traversalBuilder = RelatedTraversalBuilder.class, > elementClass = TypeB.class) > private Iterable<TypeB> typeBs; > > @GraphTraversal(traversalBuilder = RelatedTraversalBuilder.class, > elementClass = TypeC.class) > private Iterable<TypeC> typeCs; > > private static class RelatedTraversalBuilder implements > FieldTraversalDescriptionBuilder { > public TraversalDescription build(NodeBacked start, Field field) { > return new > TraversalDescriptionImpl().relationships(RelTypes.RELATED_TO); > } > } > } > > In this particular case, the traversal will return a mix of TypeB and TypeC > and throw a class cast exception. > > I'd love to have some abstraction of a Path such that path.startNode() and > path.endNode() would return the actual NodeBacked classes themselves, so I > could write my PathMappers to use something like: > > class MyPathMapper implements PathMapper { > public Void mapPath(GraphPath path) { > if(path.endNode() instanceof TypeB) { > return Evaluator.INCLUDE_AND_PRUNE > } else { > return Evaluator.EXCLUDE_AND_PRUNE > } > } > } > > It seems like the template should be able to provide this with something > along the lines of: > > interface PathMapper<T> { > ... > @Override > public Void mapPath(GraphPath graphPath) { > eachPath(graphPath); > return null; > } > } > > interface GraphPath { > NodeBacked startNode(); > NodeBacked endNode(); > ... > } > > The key here is, of course, that GraphPath provides NodeBacked classes > instead of primitive neo4j nodes. Beyond the simple instanceof example I > gave, I think it would also be useful for evaluating paths using on > NodeEntity properties rather than having to call > node.getProperty('somePropertyNameThatIWillProbablyMisspell'). > > Not sure if my request makes sense, or is reasonable to implement, but I > think it would certainly make my life a lot easier. > -- > View this message in context: > http://neo4j-user-list.438527.n3.nabble.com/Neo4j-Spring-Neo4jTemplate-tp2525460p2563548.html > Sent from the Neo4J User List mailing list archive at Nabble.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
