Hi Ivan, The reason for those questions is that the fix that Michael refers to only applies to saving a large number of new relationships when the start and end nodes have been previously persisted. For this condition to hold, you'd do something like persist nodes without relationships (either not created, or persist with depth 0), and then add the relationships and persist the nodes again. In this case, the OGM will create only relationships between known nodes and the optimised Cypher query will kick in. This fix does not apply to relationship entities either.
Further optimisation of the OGM queries is work in progress. Till it is released, the *workaround* to saving a large number of relationships is the above. 10-15 is not much at all- is it possible to share your code privately with me? Thanks Luanne On Wed, Nov 18, 2015 at 3:47 PM, Ivan Senic <[email protected]> wrote: > Hi Luanne, > > It's hard to answer your question, but I will try it.. > > *When you create relationships, are the nodes on either end already > persisted?* > Almost never.. It might happen that some of the nodes are already > persisted and also that all are new.. But how would I save "only the > relationship", saying I have both of nodes saved with depth 0, how would I > implement to save only the relationship, as in my entity object I have Sets > referring to the "connected" nodes? > > *Or are you creating both new nodes and relationships to those in one go > via the save with depth -1?* > Yes often I am creating at same time new nodes and relationships. I feel > like there is something with respect to this question, should I clearly > separate the saving of nodes and relationships? > > *How many relationships approximately are created via a single save?* > I can only give you app. estimate, so let's say 10-15.. > > Any idea? > > On Wednesday, November 18, 2015 at 4:22:47 AM UTC+1, Luanne wrote: >> >> Hi Ivan, >> >> When you create relationships, are the nodes on either end already >> persisted? Or are you creating both new nodes and relationships to those in >> one go via the save with depth -1? How many relationships approximately are >> created via a single save? >> >> -Luanne >> >> On Wed, Nov 18, 2015 at 6:16 AM, Michael Hunger < >> [email protected]> wrote: >> >>> Can you try neo4j-ogm 1.1.4-SNAPSHOT >>> >>> You might need to add m2.neo4j.org as maven repository with snapshots >>> enabeld. >>> >>> I think it has some fixes in this regard. >>> >>> Michael >>> >>> Am 17.11.2015 um 17:12 schrieb Ivan Senic <[email protected]>: >>> >>> Hi, >>> >>> I am quite new to neoj4 and I started using it with the neo4j-ogm to map >>> my java objects into the graph and back. I am experiencing quite a strange >>> behavior when I start saving entities via OGM into the graph. It seams that >>> the memory usage rises fast on the neo4j-server (I also experienced few OOM >>> Exceptions): >>> >>> >>> <https://lh3.googleusercontent.com/-ydCCbXByqXo/VktNm-PHijI/AAAAAAAAAG8/xp9AKbOwiqw/s1600/neo4j.png> >>> >>> >>> <https://lh3.googleusercontent.com/-_wMShgRo8RE/VktNhEFxoPI/AAAAAAAAAG0/YdVArB8EzkU/s1600/neo4jGoesOutOfMemory.png> >>> >>> >>> >>> As you can see from screens the memory rises up in terms of the seconds. >>> I started by saving with depth of 1 (behavior described by pic1) and then >>> also tried with depth -1 (that's pic 2 where I always hit OOM exception)., >>> It's important to mention that saving is also very slow, making some of my >>> requests time-out (with 3 seconds time out).. Setting the depth to 0 works >>> as expected (in terms of memory and speed), but then I get no relationships >>> in the graph. >>> >>> >>> The interesting thing is that I am not saving too much data at all. In >>> my use-case I end up with about 6k nodes and 6k relationships when all >>> requests are processed. Imo that's nothing for the neo4j, thus I am >>> surprised I am seeing this. >>> >>> >>> With the graph I am trying to represent all the classes (interfaces, >>> annotations, methods, etc) that are loaded in the JVM by starting a small >>> example application. So with every new class being loaded I need to update >>> the graph in order to store information I can read from the byte-code. >>> >>> >>> The only "special" thing might be that I have a lot of bi-directional >>> relationships (for example class implements interface, interface is >>> realized by class) .. Here are some screens of my graph: >>> >>> >>> >>> <https://lh3.googleusercontent.com/-_Ew1FYyCCMY/VktQwWRY4GI/AAAAAAAAAHQ/2SoTJZzuIoU/s1600/neo2.png> >>> >>> >>> <https://lh3.googleusercontent.com/-42s8twVJgyI/VktQtfxQIXI/AAAAAAAAAHI/I9D4w5byjaE/s1600/neo1.png> >>> >>> >>> It must be that I am doing something wrong.. And it has to be related to >>> the OGM.. It can not be that saving such a small number of nodes pushes the >>> memory so high.. >>> >>> Here are some more information about my setup: neo4j 2.3.0, neo44-ogm >>> 1.1.3, Ubuntu 14.04, JDK 1.7.0_70. I have no special settings than the >>> default ones. >>> >>> Any help would be great.. >>> >>> >>> -- >>> 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.
