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.
