Hi, In 1.7 RC1 which was published today there is no difference in management edges in tx and no tx mode, but we suggest to wait till Monday and use 1.7-SANPSHOT which will contain migration tool.
On Thu, Feb 6, 2014 at 7:28 PM, Dexter Pratt <[email protected]>wrote: > Updating this issue - > Found another situation where apparently framed vertex transaction mode > operations on an object created in OrientGraphNoTx mode resulted in > unintended removal of edges, so it was not an isolated case. We tried > switching our application to use only OrientGraphNoTx and the problem > went away. > > Our plan is to move to 1.7 and reproducing the behavior in that system > before attempting to diagnose since for the short term we can get by > without transactions. > > Dexter > > > On Sunday, January 19, 2014 11:19:39 AM UTC-8, Dexter Pratt wrote: >> >> Hi all, we've been working with OrientDB for several months on the NDEx >> project (www.ndexbio.org) , but this is my first post. >> >> We are currently running in 1.6.1. Most of our interface to OrientDB is >> via a Frames data model. >> >> I've encountered a problem that is proving difficult to debug because it >> seems to be (1) dependent on the mode of creation and population of the >> stored objects and (2) the problem disappears if I breakpoint my code and >> inspect the objects prior to commit. >> >> So, rather than starting by asking the for help and providing lots of >> detail on the code, I'm going to outline the problem and ask for advice on >> how to pin this problem down, how to generate a better bug to diagnose. >> >> The essence of the problem: >> - INetwork is class of object that is managed by a tinkerpop VertexFrame >> with both properties and adjacencies. >> - For one group of INetwork objects, when we perform an update on an >> INetwork to set one or more properties, the adjacencies are reset - all >> links are lost. >> - BUT, this does NOT happen for another group of INetwork objects. The >> properties are changed correctly and the links are not affected. >> - The most obvious difference between the two groups is that they were >> created using different code. The group affected by the bug was created >> under an OrientGraphNoTx connection as part of a "massive upload" >> strategy. The group not affected was created in standard transaction mode. >> - There is no obvious difference in the links when inspected in the >> console and both groups of graphs operate correctly in our application, all >> queries apparently operating without any difference (at least not that we >> have detected) >> - FURTHER, if the update operation is breakpointed in Eclipse and the >> INetwork object is inspected in the debugger, and then the code is resumed, >> then the update operation behaves correctly and the links are not affected. >> >> My current theory is therefore that there is something different between >> the two groups of stored INetworks that affects how the record is loaded by >> the VertexFrame. I might guess that the difference stems from the use of >> OrientGraphNoTx to load the "vulnerable" group, but I have no proof of >> that. And finally, it seems that the act of debug inspection causes >> alteration in the state of the VertexFrame such that the bug is averted. >> >> Thanks for any insights! I look forward to participating in this >> community. Our project is entirely open source, the repos are at >> https://github.com/cytoscape >> >> - Dexter Pratt >> > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" 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/groups/opt_out. > -- Best regards, Andrey Lomakin. Orient Technologies the Company behind OrientDB -- --- You received this message because you are subscribed to the Google Groups "OrientDB" 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/groups/opt_out.
