Hi to all, These all sound great Michael.
Towards SDG 2.x, may I suggest the addressing of two issues I've faced with neo4j & SDG a) Inheritance & Polymorphic Queries (as discussed in http://neo4j.org/forums/#nabble-td3332111) In short, having @NodeEntity public class Customer extends Person{...} being able to do a customerRepository.findByPropertyValue("name", "Smith"); instead of (Customer)personRepository.findByPropertyValue("name", "Smith"); although "@Indexed String name" is declared only in Person. Also @Indexed fields could be (declared as) replicate-able on their own separate index per subclass, thus getting separate index speed improvement (i.e searching only among my 1.000 customers, instead of the 1.000.000 persons) if this is deemed useful. Also, it would interesting to have a method with generics like personRepository.findByPropertyValue(Class<T extends Person> class, "name", smith") that searches and returns objects of some subclass of Person (ie Customer). b) Supernode navigation, as discussed in http://neo4j.org/forums/#nabble-td3144803 and elsewhere. In short, it would be useful to be able to declare a node as being a "supernode" (on some specific relationship & direction), thus having separate indexes and a relationship expander technique when accessing it (via possibly another relationship). I think this might be quite tricky to handle within SDG unless its somehow provided. Best Regards On Tue, Oct 4, 2011 at 3:47 PM, Michael Hunger < [email protected]> wrote: > Hi, > > I just wanted to share the news around the next version of the Spring Data > Neo4j project with you. > > First of all - the library will be renamed to Spring Data Neo4j and the > next release will be version 2.0 > due to the many breaking changes and new approaches. The new github > repository can be found at > > http://github.com/springsource/spring-data-neo4j > > the old one will stay around for a while (as there are some forks and > watchers) and point to the new one. > We plan to release a milestone around the end of the week and the release > candidate in time for Spring One. > > We've gotten a lot of feedback and some contribution to the library - thank > you all for that. > > From the feedback we've seen that many people are not comfortable using > full blown AspectJ to handle their > mapping. So we've decided to expand the approach - the AspectJ mapping will > be available as separate library > but the main Spring Data Neo4j project will use a mapping that is more in > line with the other Spring Data > projects using the mapping facilities from Spring Data Commons. > > The project will be split into separate parts: > > * spring-data-neo4j - contains all the core code, annotations, template, > repository support and Spring Data Commons Mapping based persistence > * spring-data-neo4j-aspects - contains the aspects for the field > interception and the Active Record like method introduction as separate > mixin > * spring-data-neo4j-cross-store - contains additional handling for JPA (and > other) cross store implementations > * spring-data-neo4j-rest - will use the neo4j-java-rest-binding and provide > a thin integration layer for Spring Data Neo4j > > Some features that we're currently discussing / are going to address: > > * provide complete object-graph persistence based on spring-data-commons > mapping > * direct-field access mapping (using AJ) will probably limited to tx-scope > * remove current lifecycle handling in favor to an explict detach operation > that uses one of the strategies outlined below > * examples will be included in the library and always up to date > * REST Batch Mode > * extensive documentation updates > * a version of the cineasts tutorial to work against REST server > * address open jira issues like multiple same type relationships, traversal > results, serialization, type-identifier-indirection > * much more > > Planned: > * Cypher DSL + Query-DSL support > * derived finder support > > I'm still discussing a important issue for the mapping - namely loading > strategies. So far I have about 5-6 ways to think about none of which I > think is the best fit, so getting input on this would be great too. > > #1 static declarations on @RelatedTo* annotations (like in JPA) -> don't > like b/c of context ignorance > #2 dynamic programatic fetching within the session context (by navigating > the required relationships) > #3 use-case specific fetch-groups, declarative (w/ annotations) + > use-case/fetch-group name as context when loading (would be also possible > with repository annotations) > #4 use-case specific fetch groups that are "auto-learned" by the > infrastructure when the user navigates relationshiops manually and then are > stored as meta information so that at the next fetch with that use-case > pre-fetches the data > #5 declare/define fetch-groups as cypher-queries or traversals (which might > also be the "metadata" for #4) > #6 have a use-case specific version of the domain objects that just contain > the subgraph that the use-case is interested in and no outgoing > relationships elsewhere (aka. DDD aggregate) then the infrastructure can > fetch this whole subgraph and return it, with the projection abilities the > entities can still be projected to other types (and the fetch-group-subgraph > could probably used within the domain model to define > mapping-contexts/boundaries (DDD again). > > Paradox of choice as always. I'd prefer either something like 5 as the > advanced version or #6 as type safe explicit one. But probably something > simpler for the start would be more sensible. > > Looking forward to your feedback for this roadmap and any helpful input you > can provide. > > Thanks > > 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
