Thanks. On Sun, Feb 20, 2011 at 10:18 PM, Michael Hunger <michael.hun...@neotechnology.com> wrote: > Alfredas, > > very interesting ideas. I think that kind of repository would have to be > built in your application, _but_ we should provide the building blocks so > that you can easily put it together.
Yep. I certainly feel that the methods i'm trying to assemble could be part of the generic repo provided. > > I'm thinking about providing support for Repositories in the Hades/Spring JPA > style where you get a generic repository as base with additional > finder-method-name parsing and whatever you add to that > as a kind of custom extension gets exposed in your repo too. Yes. Exactly. The way i'm providing the generic methods right now is in the fashion of: List<T> findByTraversalDescription(TraversalDescription td) List<T> findByPipeline(Pipeline pipe) List<T> findBySparql(String query) > > So if you're interested in this we can make this a use case for the M4 > release of Spring-Data-Graph and experiment with that. Sure. That would be very interesting. > > I'm currently working on the Neo4jTemplate API for Spring-Data-Graph, if you > (or anyone else) would like to look at that and provide feedback, I'd be > happy. > > http://gist.github.com/835408 Will do. > > I think you spotted a least issue with the relateTo. Currently it assumes > that you relate the father -> OUTGOING -> child. (Would you please try > child.relateTo(father) for incoming rels and communicate the results). > The child.relateTo(father) when child --outgoing--> father works fine. It seems that one should rather just use collections (add/remove) instead of relateTo as it might be confusing. Is there any reason to provide that method? > That is because it doesn't rely existing annotated relationships when doing > that operation. I could extend it in looking for such annotated fields and > use the values given there. > But then you can also just add the child to the collection to create the > relationship. > > > Cheers Michael > > > Am 20.02.2011 um 21:22 schrieb Alfredas Chmieliauskas: > >> On Sun, Feb 20, 2011 at 8:20 PM, Michael Hunger >> <michael.hun...@neotechnology.com> wrote: >>> all finders map back to the underlying graph so it doesnt matter which one >>> to use. >>> >>> one could still add a toVertex wrapper to your domain objects to have them >>> be usable in tinkerpop >>> >>> what is the usecase you want to achieve with the combination of spring data >>> graph and tinkerpop >>> >> So far I'm just experimenting with different ways query the graph :-) >> In the end I hope to build an "AbstractRepository<T>" class that would >> allow me to find things in the same underlying graph using >> TraversalDescriptions, Pipes, Gremlin or even SPARQL. >> Having that would add a lot of flexibility in writing domain methods. >> >>> glad that spring data graph works well for you if you have any feedback or >>> issues just ping me >> >> Yes. Spring data is very interesting. Although I am still trying to >> understand how to query a graph of heterogeneous nodes and >> relationships and discover patterns. >> >> A quick/trick question: >> I noticed that father.relateTo(child, RelationshipTypes.PARENT) works >> only if father has Direction.BOTH or Direction.OUTGOING; and >> >> @RelatedTo(type = "PARENT", elementClass = Person.class, direction = >> Direction.INCOMING) >> private Set<Person> children; >> .... >> father.relateTo(child, RelationshipTypes.PARENT); >> .... >> father.getChildren() >> >> would return empty in case of Direction.INCOMING >> >> this might be confusing! >> >> Thanks, >> >> Alfredas >> _______________________________________________ >> 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 > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
