Ok good :) Last question: What is the best way to be warned about the future evolution of SDN, releases, and especially those tested for a production environment ? Would you recommend the dedicated site (http://projects.spring.io/spring-data-neo4j/) ? A blog ? A .. tweet? :):)
Indeed, what I check until now is the dedicated site, and when I see 3.0.1 RELEASE (GA), I'm not thinking about "Ok, release *but not recommended for production*" :) Thanks a lot for all your answers, it really helps me :) Michael On Tuesday, April 1, 2014 12:05:38 PM UTC+2, Michael Hunger wrote: > > Right, so most probably a bug :) of an too eager implementation. > > > On Tue, Apr 1, 2014 at 11:58 AM, Michael Azerhad > <[email protected]<javascript:> > > 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] <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.
