Re: [Neo4j] Spring Data Graph / Neo4j – Problems with OO Inheritance Polymorphism relation semantics
2011/10/29 Agelos Pikoulas agelos.pikou...@gmail.com
Thank you Jean-Pierre/James for your answer - what you propose is certainly
one valid way of doing it, but it is still doesnot feel like a 'natural'
way
: It doesn't allow the dynamic 'navigation' of bean properties that are
them
selves Collections that each entry might have other Collections etc.
For instance I might have a User which has a getFollowers() or
getLikedObjects() etc and I want to display some of their stuff, following
some display logic etc :-) Perhaps this wouldn't be the most elegant way
MVC
wise, but I am not a spring/jsp/mvc expert anyway.
I just remembered that there is an iterator() method on collections in some
newer servlet implementations (maybe a servlet 3 spec?). So this is
possible:
c:forEach items=${device.measurements.iterator() } var=measurement
c:out value=${measurement.collector.name} /
/c:forEach
We are using tomcat 7 (inside Virgo 3) and it works.
Best regards,
James
Surelly this isn't SDN's fault, but JSP's. It would though be very helpful
(and perhaps its a twoliner) if we could annotate @Query on more (immutable
or not) Collection/iteration interfaces, say Iterator for a start
Regards
On Thu, Oct 27, 2011 at 10:01 PM, Jean-Pierre Bergamin
jpberga...@gmail.com
wrote:
Hi Agelos
Regarding your 2nd point:
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.
From the controller, just pass the iterator of the iterable to your JSP.
With Spring MVC, this would look like:
@RequestMapping(method = RequestMethod.GET)
public String list(Model uiModel) {
uiModel.addAttribute(kpis, kpiRepository.findAll().iterator());
return secure/kpis/list;
}
In your JSP, you then can use this iterator as expected:
c:forEach items=${kpis} var=kpi
tr
tdc:out value=${kpi.uuid} //td
tdc:out value=${kpi.name} //td
/tr
/c:forEach
Best regards,
James
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Spring Data Graph / Neo4j – Problems with OO Inheritance Polymorphism relation semantics
Thank you Jean-Pierre/James for your answer - what you propose is certainly
one valid way of doing it, but it is still doesnot feel like a 'natural' way
: It doesn't allow the dynamic 'navigation' of bean properties that are them
selves Collections that each entry might have other Collections etc.
For instance I might have a User which has a getFollowers() or
getLikedObjects() etc and I want to display some of their stuff, following
some display logic etc :-) Perhaps this wouldn't be the most elegant way MVC
wise, but I am not a spring/jsp/mvc expert anyway.
Surelly this isn't SDN's fault, but JSP's. It would though be very helpful
(and perhaps its a twoliner) if we could annotate @Query on more (immutable
or not) Collection/iteration interfaces, say Iterator for a start
Regards
On Thu, Oct 27, 2011 at 10:01 PM, Jean-Pierre Bergamin jpberga...@gmail.com
wrote:
Hi Agelos
Regarding your 2nd point:
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.
From the controller, just pass the iterator of the iterable to your JSP.
With Spring MVC, this would look like:
@RequestMapping(method = RequestMethod.GET)
public String list(Model uiModel) {
uiModel.addAttribute(kpis, kpiRepository.findAll().iterator());
return secure/kpis/list;
}
In your JSP, you then can use this iterator as expected:
c:forEach items=${kpis} var=kpi
tr
tdc:out value=${kpi.uuid} //td
tdc:out value=${kpi.name} //td
/tr
/c:forEach
Best regards,
James
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Spring Data Graph / Neo4j – Problems with OO Inheritance Polymorphism relation semantics
On the same Iterable problem (deviating from the main OO question
unwillingly),
I 've made my own IterableSomeclass property which is backed by a
ListSomeclass filled at runtime using the @Query backed Iterable (thus
enabling my class filtering to solve the main OO question) and the JSP
works fine... When I substitute with the @Query filled Iterable directly I
get:
javax.servlet.jsp.JspTagException: Don't know how to iterate over
supplied items in lt;forEachgt;
Surely this is a JSP error, but how do we solve it ?
On Sat, Oct 29, 2011 at 8:16 PM, Agelos Pikoulas
agelos.pikou...@gmail.comwrote:
Thank you Jean-Pierre/James for your answer - what you propose is certainly
one valid way of doing it, but it is still doesnot feel like a 'natural' way
: It doesn't allow the dynamic 'navigation' of bean properties that are them
selves Collections that each entry might have other Collections etc.
For instance I might have a User which has a getFollowers() or
getLikedObjects() etc and I want to display some of their stuff, following
some display logic etc :-) Perhaps this wouldn't be the most elegant way MVC
wise, but I am not a spring/jsp/mvc expert anyway.
Surelly this isn't SDN's fault, but JSP's. It would though be very helpful
(and perhaps its a twoliner) if we could annotate @Query on more (immutable
or not) Collection/iteration interfaces, say Iterator for a start
Regards
On Thu, Oct 27, 2011 at 10:01 PM, Jean-Pierre Bergamin
jpberga...@gmail.com wrote:
Hi Agelos
Regarding your 2nd point:
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.
From the controller, just pass the iterator of the iterable to your JSP.
With Spring MVC, this would look like:
@RequestMapping(method = RequestMethod.GET)
public String list(Model uiModel) {
uiModel.addAttribute(kpis, kpiRepository.findAll().iterator());
return secure/kpis/list;
}
In your JSP, you then can use this iterator as expected:
c:forEach items=${kpis} var=kpi
tr
tdc:out value=${kpi.uuid} //td
tdc:out value=${kpi.name} //td
/tr
/c:forEach
Best regards,
James
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Spring Data Graph / Neo4j – Problems with OO Inheritance Polymorphism relation semantics
Thank you Michael - wish you 'll have a great conference we're all
looking forward for the online materials :-)
On Wed, Oct 26, 2011 at 8:14 PM, Michael Hunger
michael.hun...@neotechnology.com wrote:
Angelos, I'm currently at SpringOne and quite swamped, I get back to you as
soon as possible.
Michael
Am 26.10.2011 um 04:30 schrieb Agelos Pikoulas:
On my previous email please excuse my confusing Person, the example
should
clearly be like this :
*
*
*@NodeEntity public class Content {}*
* *
*@NodeEntity public class ExtContent extends Content {}*
*@NodeEntity
public class Person {
@RelatedToVia(elementClass = Person.class, type = LIKES, direction =
Direction.OUTGOING)
private SetPerson likedPersons;
public SetPerson getLikedPersons() {return likedPersons;}
@RelatedToVia(elementClass = Content.class, type = LIKES, direction
=
Direction.OUTGOING)
private SetContent likedContent;
public SetContent getLikedContent() { return likedContent; }
}
*I am attaching the code, if someone can github it cause my eclipse
plugin
refuses to do so :-(*
*
On Wed, Oct 26, 2011 at 12:54 AM, Agelos Pikoulas
agelos.pikou...@gmail.com
wrote:
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 SetPerson getLikedPersons() {return
likedPersons;}
@RelatedToVia(elementClass = Person.class, type =
LIKES,
direction = Direction.OUTGOING)
private SetPerson likedPersons;
public IterableContent getLikedContent() { return
likedContent; }
@Query (start n=node({self}) match (n)
-[:LIKES]-(content) return content)
@RelatedToVia(elementClass = Content.class, type =
LIKES, direction = Direction.OUTGOING)
private IterableContent 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, IterableContent 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
Re: [Neo4j] Spring Data Graph / Neo4j – Problems with OO Inheritance Polymorphism relation semantics
Hi Agelos
Regarding your 2nd point:
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.
From the controller, just pass the iterator of the iterable to your JSP.
With Spring MVC, this would look like:
@RequestMapping(method = RequestMethod.GET)
public String list(Model uiModel) {
uiModel.addAttribute(kpis, kpiRepository.findAll().iterator());
return secure/kpis/list;
}
In your JSP, you then can use this iterator as expected:
c:forEach items=${kpis} var=kpi
tr
tdc:out value=${kpi.uuid} //td
tdc:out value=${kpi.name} //td
/tr
/c:forEach
Best regards,
James
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Spring Data Graph / Neo4j – Problems with OO Inheritance Polymorphism relation semantics
On my previous email please excuse my confusing Person, the example should
clearly be like this :
*
*
*@NodeEntity public class Content {}*
* *
*@NodeEntity public class ExtContent extends Content {}*
*@NodeEntity
public class Person {
@RelatedToVia(elementClass = Person.class, type = LIKES, direction =
Direction.OUTGOING)
private SetPerson likedPersons;
public SetPerson getLikedPersons() {return likedPersons;}
@RelatedToVia(elementClass = Content.class, type = LIKES, direction =
Direction.OUTGOING)
private SetContent likedContent;
public SetContent getLikedContent() { return likedContent; }
}
*I am attaching the code, if someone can github it cause my eclipse plugin
refuses to do so :-(*
*
On Wed, Oct 26, 2011 at 12:54 AM, Agelos Pikoulas agelos.pikou...@gmail.com
wrote:
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 SetPerson getLikedPersons() {return
likedPersons;}
@RelatedToVia(elementClass = Person.class, type = LIKES,
direction = Direction.OUTGOING)
private SetPerson likedPersons;
public IterableContent getLikedContent() { return
likedContent; }
@Query (start n=node({self}) match (n)
-[:LIKES]-(content) return content)
@RelatedToVia(elementClass = Content.class, type =
LIKES, direction = Direction.OUTGOING)
private IterableContent 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, IterableContent 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
Re: [Neo4j] Spring Data Graph / Neo4j – Problems with OO Inheritance Polymorphism relation semantics
Angelos, I'm currently at SpringOne and quite swamped, I get back to you as
soon as possible.
Michael
Am 26.10.2011 um 04:30 schrieb Agelos Pikoulas:
On my previous email please excuse my confusing Person, the example should
clearly be like this :
*
*
*@NodeEntity public class Content {}*
* *
*@NodeEntity public class ExtContent extends Content {}*
*@NodeEntity
public class Person {
@RelatedToVia(elementClass = Person.class, type = LIKES, direction =
Direction.OUTGOING)
private SetPerson likedPersons;
public SetPerson getLikedPersons() {return likedPersons;}
@RelatedToVia(elementClass = Content.class, type = LIKES, direction =
Direction.OUTGOING)
private SetContent likedContent;
public SetContent getLikedContent() { return likedContent; }
}
*I am attaching the code, if someone can github it cause my eclipse plugin
refuses to do so :-(*
*
On Wed, Oct 26, 2011 at 12:54 AM, Agelos Pikoulas agelos.pikou...@gmail.com
wrote:
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 SetPerson getLikedPersons() {return
likedPersons;}
@RelatedToVia(elementClass = Person.class, type = LIKES,
direction = Direction.OUTGOING)
private SetPerson likedPersons;
public IterableContent getLikedContent() { return
likedContent; }
@Query (start n=node({self}) match (n)
-[:LIKES]-(content) return content)
@RelatedToVia(elementClass = Content.class, type =
LIKES, direction = Direction.OUTGOING)
private IterableContent 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, IterableContent 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
