To add my 3 cents (inflation!) worth: I love the power of AspectJ, and in particular areas it's fantastic. e.g. Spring Insight uses weaving of aspects to give very focused and lightweight probing to an application running under Tomcat/tcServer.
For tooling, the Eclipse support is excellent, partly driven by Spring Roo's leverage of AspectJ (e.g. in Spring Tool Suite). IntelliJ support has unfortunately been very much lacking and is having to catch up from a low level. I considered a similar approach to Neo in implementing Spring Data support for Whirlwind Match's fuzzy database, but so far, I've found the Spring Data Commons support sufficient for the use cases I've hit. With this in mind I'd say that providing a non-AspectJ option would be beneficial. Also, some enterprises have policies against certain tooling, such as load-time weaving. I think it's much less of an issue with compile time weaving, and perhaps commercially the key is that developers are isolated from the implementation, rather than needing to understand it. I doubt many Spring developers could explain where CGLIb and Asm and AspectJ are used in Spring. They usually don't care, so long as it works :) Cheers, Neale On 30 September 2011 10:08, Michael Hunger <[email protected] > wrote: > 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 > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
