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.
