Hi Dexter, Could you try following either use "develop" branch or use 1.6.4 version with flag mvrbtree.ridBinaryThreshold set to -1 (-Dmvrbtree.ridBinaryThreshold=-1) ?
On Sun, Jan 19, 2014 at 9:19 PM, Dexter Pratt <[email protected]>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.
