Hey Chris, sorry for the late response, I'm in Linz presenting SDN at the JUG with bad Hotel internet connection last night.
With the feedback we got regarding AJ before we are reworking our approach. That means there will be two ways of handling object mapping in SDN. I also want to ease the AJ approach. #1 Having a simple version that just takes care of property/relationship mapping and does not introduce any additional methods. This kind of entities you would use with repositories. #2 if you'd like to there would be an "ActiveRecord" mixin (also using AJ) that adds those additonal methods and would you not to require repositories #3 I'm working on the non AspectJ mapping, as I'm on the road I don't know if I can get it ready by the weekend as I first had to migrate the underlying infrastructure. I'm also thinking about limiting the AJ approach to session scope (i.e. transactional) again, this would get rid of the overly complex lifecycle (attach-detach handling). For non-transactional handling (e.g. in the web-layer) we could fall back to the load-store-pattern. With the renaming to Spring Data Neo4j we also got a new repository that is on http://github.com/springsource/spring-data-neo4j which now also includes the examples and will also contain the roo addon. The changes will provide a spring-data-neo4j library which contains the infrastructure and the non-aj mapping and a separate spring-data-neo4j-aspects which contains the aspects and mixins. 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. Cheers Michael Am 29.09.2011 um 23:52 schrieb Chris: > Hi Andreas, > > I would be willing to work with the bleeding edge snapshots if it would help > you guys out. Also, Emil's note about the benefits of AspectJ are > interesting and I'm going to think on them more as well. I suppose I could > create the domain objects in a separate jar and then include it like any > other jar. At that point, I wouldn't need the AJC compiler unless the domain > objects changed - that's something I'll keep in mind. Thanks Emil for > presenting that perspective. > > But anyway, I'm always interested in playing with new technology - where > should I get them from? Let me know and I'll try to give it a go this > weekend. My app is pretty simple, just normal budgeting entities - ledgers, > transactions, etc but still something that I think Neo4J would be better for > using than JPA type entities. > > Thanks, > > Chris > > On Thu, Sep 29, 2011 at 1:51 PM, Andreas Kollegger > <[email protected]> wrote: > Hi Chris, > > I'll second Emil's appreciation of your thoughtful feedback. That is > incredibly valuable, and really: your timing could not be better. > > Among the features of the next major release of SDN will be an annotated POJO > approach which does not require AspectJ to weave in accessors and extra > utility methods for the entity. We're still in the midst of coding up the > implementation, aiming for a release by SpringOne in Chicago. > > For you personal project, would you be willing to work with bleeding-edge > snapshots to evaluate the direction we're headed? > > Cheers, > Andreas > > On Sep 29, 2011, at 12:31 PM, Emil Eifrem wrote: > >> Thanks Chris for your thoughtful response. >> >> AspectJ gives you several advantages. In particular, you can move away from >> the traditional load/store entity workflow where you use an entity manager >> to get data out of the database, translate it to a disconnected entity, work >> on that entity and then store it back through the entity manager. Instead, >> with AspectJ you work with a transaction-oriented workflow where you open up >> a transaction, then just work with your POJOs without having to track them >> and when you commit the transaction all data will automagically end up in >> the graph. A very powerful model. >> >> Having said that, we have heard the same feedback about AspectJ before. >> Andreas or Michael (in cc), do you want to follow up with Chris and talk >> about our plans for Spring Data Neo4j 2.0 and what we intend to do about >> AspectJ? >> >> Thanks again Chris for your feedback and kind words. Appreciate it. >> >> Cheers, >> >> -EE >> >> On Thu, Sep 29, 2011 at 06:48, Chris <[email protected]> wrote: >> Emil, >> >> This is Chris Shellenbarger (64BitChris) , thank you for your tweet, what >> follows is my reply to your questions: >> >> As for what I like about SDN, it's not SDN in particular that I'm familiar >> with, but the Spring Framework in general. I believe that Spring allows me >> to focus more on my application specific code and let Spring take care of >> all the boilerplate stuff. For this reason, I was interested in using >> Spring Data for persistence. When I posted that tweet about AspectJ, I was >> trying to use Neo4J to data in a budgeting application. I had heard good >> things about Spring Data and I like how it works with JPA objects so I >> figured I'd enjoy the Neo4J support. >> >> As a sidenote, I've had my eye on Neo4J for a machine learning application >> that I am the architect of in my day job. We use RDF/OWL triple stores >> right now to help us create temporally consistent states of the world at any >> given time. I think that Neo4J could be a good fit for this type of data. >> I wanted to try out Neo4J on my personal project mentioned above so I could >> better understand it before I championed its use in my work project. >> >> So, that leads us to AspectJ. The biggest problem that I can see with the >> technology is that a lot of people don't understand how it works. Some of >> them still can't grasp the Spring IOC/DI patterns and get lost in the XML. >> Compile or Load time weaving is something that is, in my opinion, more >> advanced than Spring configuration. It's hard to look at a source file and >> then know all of the aspects that will be applied so we just assume 'magic' >> happens at compile or load time. It can also cause problems with IDEs and >> debugging if the IDE doesn't fully support AspectJ (IntelliJ 11 will have >> more support, not sure about the current state of eclipse). Also, we have >> to run the special AJC compiler. >> >> I could advocate that we take a look at Neo4J in my work projects, but as >> soon as people hear the word 'AspectJ', they seem to have a major aversion >> to it. The other graph (RDF triple) stores we are looking at (AllegroGraph, >> etc) don't seem to require this technology. So, I have to balance the >> ability to get my engineers on board with the technology with the value that >> we receive from the technology. Right now, Neo4J seems like it could >> provide a lot of value to us, but my engineers will resist it because of >> AspectJ. >> >> With all that said, I want to tell you that everything I've heard about >> Neo4J is great. I've followed your progress for a while and I think your >> technology is incredibly exciting. I believe that graph datastores have a >> great future ahead of it and that Neo4J has the potential to emerge as the >> leader in the field in the long run. Keep up all the great work and it will >> be! >> >> >> Thanks, >> Chris Shellenbarger >> >> >> >> >> -- >> Emil Eifrém, CEO [[email protected]] >> Neo Technology, www.neotechnology.com >> Cell: +46 733 462 271 | US: 206 403 8808 >> http://blogs.neotechnology.com/emil >> http://twitter.com/emileifrem > > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
