Right, so most probably a bug :) of an too eager implementation.

On Tue, Apr 1, 2014 at 11:58 AM, Michael Azerhad
<[email protected]>wrote:

> But.. it seems right to use the ManagedFieldAccessorSet for a Lazy
> collection, to fetch on access...so my post above is a nonsense :)
>
> What I don't figure out is why there is the *managed* notion if I don't
> do anything to work with AspectJ mapping mode.
> All objects aren't all detached when retrieved in Simple Mapping mode ?
>
> Thanks,
>
> Michael
>
>
> On Tuesday, April 1, 2014 11:51:32 AM UTC+2, Michael Azerhad wrote:
>>
>> Hum...no I don't think :) :
>>
>> @org.springframework.data.neo4j.annotation.RelatedTo(`type` = 
>> "KNOWS",direction
>> = Direction.BOTH)
>>   var knowledge: java.util.Set[User] = new util.HashSet[User]
>>
>> Here's my real usage and there is not an @Fetch on it. :(
>>
>> On Tuesday, April 1, 2014 11:45:03 AM UTC+2, Michael Hunger wrote:
>>>
>>> I rather think that the managed field accessor set is too eager in what
>>> it is doing :)
>>>
>>> There are no transactions over the wire.
>>>
>>>
>>> On Tue, Apr 1, 2014 at 11:24 AM, Michael Azerhad 
>>> <[email protected]>wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> Indeed, you're right... the type of the returned collection is managed: * 
>>>> "org.springframework.data.neo4j.fieldaccess.ManagerFieldAccessorSet..",
>>>> *explaining so why "clear()" has an impact.
>>>>
>>>> Perhaps, it's the usage of java-rest-binding combined
>>>> spring-data-neo4j-rest that batches for write transactions (indeed, I use
>>>> the @Transactional around all my writes.).. bypassing the default
>>>> SimpleMapping mode.
>>>> I've done anything to use the aspectJ mode, neither embedded its jar.
>>>> May it be the explanation?
>>>>
>>>> By the way, SDN 3.0.0 passes all my application-focused integration
>>>> tests, so I chose to use it in my "little-hidden" production (since I'm
>>>> still building my app), in order to benefit from the labels usage and neo4j
>>>> 2.0.X, that works great :)
>>>>
>>>> If I don't start to use SDN 3.0.X, what should I use, what may you
>>>> recommend? Plain Neo4j graph APIs? Manual Cypher queries?
>>>>
>>>> Thanks a lot,
>>>>
>>>> Michael :)
>>>>
>>>>
>>>>
>>>> On Tuesday, April 1, 2014 8:17:57 AM UTC+2, Michael Hunger wrote:
>>>>
>>>>> Michael,
>>>>>
>>>>> you shouldn't use 3.0.0 in production. It has not yet been tested for
>>>>> that!
>>>>>
>>>>> Are you sure you use SDN-REST with simple mapping? It sounds like you
>>>>> get the automatic deletion on cleaning the collection. (Or it is a bug,
>>>>> related to the managed collection that's normally used to hold the related
>>>>> entities)
>>>>>
>>>>> How do you clear the child entities? Can you check the instance type
>>>>> of the collection you get back?
>>>>> It should be enough to set that collection variable to null to be
>>>>> skipped when saving the parent.
>>>>>
>>>>> Perhaps you can share a test project that reproduces the issue in a
>>>>> test, so we can look into it? Best in a JIRA issue so it doesn't get lost
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 1, 2014 at 1:04 AM, Michael Azerhad 
>>>>> <[email protected]>wrote:
>>>>>
>>>>>> I use the SDN 3.0.0 in production (I know this isn't the last
>>>>>> version).
>>>>>>
>>>>>> Basically, I have a `Parent` class (@NodeEntity) having a
>>>>>> relationship (Set[Child]) to its children, without no declared @Fetch on 
>>>>>> it.
>>>>>>
>>>>>> When I want to update the parent, I do:
>>>>>>
>>>>>>    1. Find the parent to update through the repository (findById)
>>>>>>    2. Clear the current Children collection (to avoid the entry
>>>>>>    added when having no @Fetch on the collection)
>>>>>>    3. Use a custom repository method to retrieve its current
>>>>>>    children =>  @Query("MATCH (p:Parent {id: {0}})-[:HAVE]-(child)
>>>>>>    RETURN child")
>>>>>>    4. Add all children to the parent's collection + new
>>>>>>    children (parent.addAll(children))  or other properties's values
>>>>>>    5. save the parent
>>>>>>
>>>>>> *The issue comes in step 3*:   the retrieved collection is *empty* !
>>>>>>   I'm pointing out that I'm using the simple mapping mode with REST mode,
>>>>>> so i don't understand, why the clear() method impacts its result. I think
>>>>>> that the simple mapping mode makes a copy of the object so it's detached.
>>>>>>
>>>>>> Indeed, I find this workaround:
>>>>>>
>>>>>>    1. Find the parent to update through the repository (findById)
>>>>>>    2. Use a custom repository method to retrieve its current
>>>>>>    children *and save them in a temporary variable*
>>>>>>    3. Clear the current Children collection (to avoid the entry
>>>>>>    added when having no @Fetch on the collection)
>>>>>>    4. Add all children to the parent's collection* by using the
>>>>>>    temporary variable that kept the children* + new children
>>>>>>    (explaining the necessity of an update)
>>>>>>    5. save the parent
>>>>>>
>>>>>> Here, retrieving the current children BEFORE the
>>>>>> parent.children.clear() make the whole work as expected.
>>>>>>
>>>>>> My question is:  What is the link between a clear() on a
>>>>>> relationship, and a Cypher query (through SDN-style repository). The 
>>>>>> first
>>>>>> impacting the other.
>>>>>>
>>>>>> 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.
>>>>
>>>
>>>  --
> 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.

Reply via email to