Announcement Announcement Module
No announcement yet.
Spring Data Neo4j 2.0 Roadmap Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Data Neo4j 2.0 Roadmap


    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

    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

    * 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.



  • #2
    So this project is under Apache license 2.0. And reading at the Neo4J site, I see that it is AGPL. How do those two licenses resolve in usage of this project. I am a bit confused.

    Thanks for any clarification


    • #3
      Neo4j Community is licensed under the GPLv3 which is compatible with ASL 2.0. Only the advanced and enterprise editions are licensed AGPL/Commercial.




      • #4
        Thanks for that

        However, although I can use the Spring Data Graph for Neo4J pretty much as I choose, I would still be forced to release the source for my sown source code as per the provisions of the NE4J GPLv3 license.

        I ask this because I am very interested in building software based on this but I would like to keep my source closed for now and the GPLv3 license pretty much make that impossible if I distribute it.

        I came across this link from Sam Ruby of the Apache Foundation

        Thanks very much

        Originally posted by MichaelHunger View Post
        Neo4j Community is licensed under the GPLv3 which is compatible with ASL 2.0. Only the advanced and enterprise editions are licensed AGPL/Commercial.




        • #5
          Is 2.0 M release on Maven? Or do we still just use the SNAPSHOT repository?

          With the roadmap, does it include the ROO add-on, or is that separate?




          • #6
            Hi Mark,

            2.0.M1 is in the maven repo. We're polishing it now to put out an RC1 next week.

            The roo addon is currently hosted separately (due to some other issues) but will be moved into roo some time this year and then taken care of by the roo team.

            Right now it is partially working, there are some issues wrt updates/deletes in the controller.

            Have to update it to SDN 2.0 + Repositories anyway.