Thanks for the feedback, really appreciated. Glad you like it and looking forward to more suggestions.
Cheers, Michael On Wed, Apr 2, 2014 at 12:24 AM, Michael Azerhad <[email protected]>wrote: > 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]>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]. >>> 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.
