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
