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.
