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.
