Thanks Michael :) "Sorry, 3.0 was a weird beast" => perhaps but I'm pretty happy with it and I appreciate the job :) All what I expect it to do is well done, except the workaround, subject of this topic. As long as my acceptance tests pass, no matter what kind of bug could happen in 3.X releases for now. Except if there are "random" bugs..but it'd sound to be rare :) But as you say, setting the relationship to null instead of clearing it do the trick !
Cheers, Michael On Tuesday, April 1, 2014 2:02:20 PM UTC+2, Michael Hunger wrote: > > Sorry, 3.0 was a weird beast, as the SD release train was just too fast > for me too catch up with all the work needed for upgrading SDN to Neo4j 2.0 > > I published a blog here: > http://blog.neo4j.org/2014/03/spring-data-neo4j-progress-update-sdn-3.html > Usually tweets are good. > > And I would probably have to update this > http://projects.spring.io/spring-data-neo4j/ too > > Best is probably to ask :) > > Cheers, > > Michael > > > > On Tue, Apr 1, 2014 at 12:24 PM, Michael Azerhad > <[email protected]<javascript:> > > wrote: > >> 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]>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] <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.
