Hi to all graphistas,
I have two issues, a major and a minor : 1) 1) Starting with SDG 1.0/1.1, I have been developing a MetaModel (and a generator & hopefully later a MetaMetaModel:) and I have been facing walls in regards to @NodeEntity / NodeBacked classes inheritance and their related @RelatedXXX feature set. To the specifics, when a @NodeEntity class extends another, there is limited support to how these can consistently be related to other nodes (and retrieved) based not just on the RelationShip name, but also on their class (and inheritance/subclass tree). To better describe things, look at this simplistic example : I have @NodeEntity public class Content {} @NodeEntity public class ExtContent extends Content {} and @NodeEntity public class Person { public Set<Person> getLikedPersons() {return likedPersons;} @RelatedToVia(elementClass = Person.class, type = "LIKES", direction = Direction.OUTGOING) private Set<Person> likedPersons; public Iterable<Content> getLikedContent() { return likedContent; } @Query ("start n=node({self}) match (n) -[:LIKES]-(content) return content") @RelatedToVia(elementClass = Content.class, type = "LIKES", direction = Direction.OUTGOING) private Iterable<Content> likedContent; } As you can see, I want Person object/nodes to 'LIKES' other Person objects, or Content objects (and below in the inheritance tree, such as ExtContent) : @Test public void oo_testing() { Person p1 = new Person().persist(); Person p2 = new Person().persist(); Content c1 = new Content().persist(); ExtContent c2 = new ExtContent().persist(); p1.relateTo(c1, "LIKES"); p1.relateTo(c2, "LIKES"); p1.relateTo(p2, "LIKES"); for (Content cc : p1.getLikedContent()) logger.warn("Class : " + cc.getClass().getName() + ", __type__ : " + cc.getPersistentState().getProperty("__type__")); assertEquals("LikedContent objects are 2", 2, p1.getLikedContent().size()); // fails, cause it returns all of 'LIKES' related nodes } In version 1.1.RELEASE, retrieving any of the collections fails at rutime (can't recall the Exception, but it was the sort of "wrong class found"). In version 2.0.0.M1 & today's 2.0.0.BUILD-SNAPSHOT, getLikedPersons() & getLikedContent() both contain ALL nodes that are related via 'LIKES' relationship, irrespective of class. So, this is what p1.getLikedContent() contains : Class : sdnTests.domain.Content, __type__ : sdnTests.domain.Person Class : sdnTests.domain.Content, __type__ : sdnTests.domain.Content Class : sdnTests.domain.ExtContent, __type__ : sdnTests.domain.ExtContent One would expect that since elementClass defines the class of nodes to fill the collection with, this it would be obeyed. To a better extend, Iterable<Content> likedContent should contain all object/nodes of type Content AND Content subclasses (eg ExtContent), since do we have this type information. The same lacking of OO/polymorphism exists with repositories, as discussed here http://lists.neo4j.org/pipermail/user/2011-October/012654.html (haven’t tested this with 2.0.0.M01, I m still on 1.1) One can overcome these problems by hand & on top of SDN, but I guess it wouldn't be very elegant & efficient - I think SDN should inherently allow these OO/polymorphic features and emerge itself as a lean & robust OO + Graph repository. 2) 2) The minor issue I have regards (the otherwise brilliant) @Query, due to its constraint of annotating (mainly) Iterable and NOT allowing Set, List etc (a runtime exception is thrown org.springframework.data.neo4j.conversion.QueryResultBuilder$1 cannot be cast to java.util.List). This wouldn’t be a huge problem, but the JSP/JSLT <forEach> tag DOESNOT iterate Iterable (!!!), nor you can directly call .iterator() from within JSP, making life hard on both ends. Regards _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user