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]<javascript:> > > 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] <javascript:>. >> 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.
