I also confirm that is the explanation :)
Indeed, I had a bad hashcode implementation:
override def hashCode(): Int = {
if (_id == null)
0 // a constant value acting as a dummy value ... I imagined that
this case should never happened, but as Spring-Data works, it happens :)
else
_id.hashCode()
}
Explaining why a manual fetch doesn't retrieve all elements....they had all
the same hashcode => 0 !
Now I have:
override def hashCode(): Int = {
if (_id == null)
System.identityHashCode(this)
else
_id.hashCode()
}
And it well works :)
Michael
On Tuesday, May 20, 2014 2:27:56 PM UTC+2, Michael Hunger wrote:
>
> Oh, that's the solution? *sigh*
>
> It's kinda hard to define other equality if you don't have more
> information available than just the GraphId.
>
>
> On Tue, May 20, 2014 at 2:20 PM, Mark Findlater
> <[email protected]<javascript:>
> > wrote:
>
>> Ha, you know what, whilst I have been disappeared I have had a thought
>> and I'm going to guess that the problem (for me) stems from not performing
>> equality/hash based on the graphId field and therefore ending up with a
>> load of nodes that are "equal" and subsequently occupy a single slot in the
>> set. Well I wish I'd realised that when I started, there is a lot of
>> behaviour to modify now!
>>
>> M
>>
>>
>> On Monday, 28 April 2014 14:37:30 UTC+1, Mark Findlater wrote:
>>>
>>> Sorry, I didn't see this reply! Interestingly I just came across the
>>> problem again, I can write a unit test, I have unit tests but it is quite a
>>> lot of code to reproduce, so I can trim it down. In the meantime should I
>>> assume that this is not a problem that anyone other than myself and Michael
>>> A are experiencing?
>>>
>>> Thanks,
>>>
>>> M
>>>
>>> On Thursday, 17 April 2014 05:49:10 UTC+1, Michael Hunger wrote:
>>>>
>>>> As simple mode is detached from the db you should need to save it again
>>>> to persist changes
>>>>
>>>> Mark could you create a unit test for that fetching/loading behavior?
>>>>
>>>> Thanks a lot
>>>>
>>>> Sent from mobile device
>>>>
>>>> Am 17.04.2014 um 02:31 schrieb Michael Azerhad <[email protected]>:
>>>>
>>>> Oh, so the problem should not be tied exclusively to Scala..
>>>>
>>>> I don't find the root cause.. I just use a workaround:
>>>>
>>>> instead of neo4jTemplate.fetch method, I wrote a repository method to
>>>> fetch the whole. Not pretty, but working..
>>>>
>>>> I would be curious too to know the exact reason of the issue..
>>>>
>>>> Michael
>>>>
>>>> On Tuesday, April 15, 2014 2:13:50 PM UTC+2, Mark Findlater wrote:
>>>>>
>>>>> I am interested in this too. I am using Neo4j 2.0.1 and SDN
>>>>> 3.0.0.RELEASE . I am experiencing the same behaviour:
>>>>>
>>>>> //When the Node is retrieved images.size() is 3 and the correct images
>>>>> are present.
>>>>> @NodeEntity
>>>>> public class SponsorNode {
>>>>>
>>>>> @RelatedTo(type="BRAND_IMAGE", direction=Direction.OUTGOING)
>>>>> @Fetch
>>>>> private Set<ImageNode> images;
>>>>> }
>>>>>
>>>>> //If I now fetch the sponsor node images.size() == 1, if I run
>>>>> template.fetch(images) then images.size() == 1 (but all attributes are
>>>>> populated).
>>>>> @NodeEntity
>>>>> public class SponsorNode {
>>>>>
>>>>> @RelatedTo(type="BRAND_IMAGE", direction=Direction.OUTGOING)
>>>>> private Set<ImageNode> images;
>>>>> }
>>>>>
>>>>> Did you find the root of your problem Michael?
>>>>>
>>>>> On Sunday, 2 February 2014 22:27:56 UTC, Michael Azerhad wrote:
>>>>>>
>>>>>> Maybe it's an incompatibility with Scala.
>>>>>>
>>>>>> I spent all day long to explain a possible reason why fetching only
>>>>>> returns the first collection's element.
>>>>>>
>>>>>> Could anyone confirm me this assumption:
>>>>>> I precise I use SDN 3.0.0-RC1 with the simple object mapping:
>>>>>>
>>>>>> *If my first action is to create and save a `Meeting` object, *
>>>>>> *then I don't need to save it anymore to be able to fetch the future
>>>>>> relationships made by adding some `Participation`s independently.*
>>>>>> *In other word, does fetching for last values require the Meeting
>>>>>> object to be saved/updated again after Participations were added?*
>>>>>>
>>>>>> Thanks a lot
>>>>>>
>>>>>> On Sunday, February 2, 2014 3:29:45 PM UTC+1, Michael Azerhad wrote:
>>>>>>>
>>>>>>> I use Scala.
>>>>>>>
>>>>>>> In my class Meeting, I have this relation:
>>>>>>>
>>>>>>> @RelatedTo(`type` = "TO", direction = Direction.INCOMING)
>>>>>>> var _participants: java.util.Set[Participation] = _
>>>>>>>
>>>>>>> Participation is another node entity, linked to Meeting with an
>>>>>>> outgoing relationship "TO".
>>>>>>>
>>>>>>> What I do is a simple test saving firstly a Meeting, and then saving
>>>>>>> three distinct Participations related to it.
>>>>>>>
>>>>>>> I expect then to have a size of 3 when I do at the end of the
>>>>>>> process:
>>>>>>> neo4jTemplate.fetch(meetingRepository.findById(justSavedMeetingId).
>>>>>>> _participants)
>>>>>>>
>>>>>>> However, it only returns the first Participation that was linked to.
>>>>>>> Not the two others....
>>>>>>>
>>>>>>> Note that it well works (size of 3 retrieved) when I add @Fetch,
>>>>>>> without explicitly using neo4jtemplate.fetch:
>>>>>>>
>>>>>>> @Fetch @RelatedTo(`type` = "TO", direction = Direction.INCOMING)
>>>>>>> var _participants: java.util.Set[Participation] = _ //works
>>>>>>>
>>>>>>> I tested it in the same transaction and in distinct transaction.
>>>>>>>
>>>>>>> Am I missed something obvious?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>> On Sunday, February 2, 2014 3:53:54 AM UTC+1, Michael Azerhad wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> My question is pretty simple:
>>>>>>>> May it be a normal scenario when neo4jTemplate.fetch returns ALWAYS
>>>>>>>> the first collection's element? (concerning a @RelatedTo collection's
>>>>>>>> field without any @Fetch annotation)
>>>>>>>>
>>>>>>>> On the contrary, when @Fetch is placed, the whole collection is
>>>>>>>> well retrieved.
>>>>>>>>
>>>>>>>> I did a workaround by rather use a Cypher Query (annotation in my
>>>>>>>> repository) to load the collection, but I would like to know if this
>>>>>>>> scenario could be explained.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Neo4j" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
