Hi Dexter, Could you send me db and code which I can use to reproduce this issue ? If there is porblem in data consistency it is quite serious and we should fix it asap.
Could you also open issue related to this problem in bug tracker ? On Tue, Sep 23, 2014 at 1:15 PM, Andrey Lomakin <[email protected]> wrote: > Hi Dexter, > Do do you have issue on this in bug tracker ? > > On Sat, Sep 20, 2014 at 1:36 AM, Dexter Pratt <[email protected]> > wrote: > >> I'm following up on a serious problem that we reported privately, I'm >> hoping that others may have seen related behavior. >> >> The critical issue is that we have found what seem to be malformed / >> corrupt edges in data that our application has loaded - but no errors >> occurred during loading. (we have scanned all of our code to be sure that >> we are not accidentally discarding errors) >> >> We are very concerned because we have just gone live with a site where >> users can upload their data and we now believe that their data is at risk - >> or may already have been compromised - in unpredictable ways. >> >> *Problem summary:* >> >> In 1.7.9-SNAPSHOT, a small fraction of edges created by our data loader >> using the Graph API via a PLOCAL connection can be found and counted by >> tools such as "load record" in the console, BUT they are not found by >> traversal queries. >> >> We previously reported (what we think was) the same behavior on a REMOTE >> connection and then we switched to PLOCAL. (see example 2 below) Initially >> we thought the problem was resolved by switching to PLOCAL, but on closer >> examination there are still error cases, such as Example 1 below. >> >> This discrepancy was difficult to find because the edge counts for the >> objects matched our expectations and we assumed the data was correct. But >> when queried, the edges were not found and so our exporter application >> produced output with missing elements. >> >> Below is an example of a record which, when examined by load record, >> shows 4 incoming edges of type in_nSupport but a traverse query returns >> only 2 edges. >> >> Is this a known issue - perhaps related to some of the recent posts? >> >> Thanks, >> >> Dexter >> >> *Example 1:* >> >> orientdb {db=ndex}> load record #22:6402 >> >> -------------------------------------------------- >> >> ODocument - Class: support id: #22:6402 v.9 >> >> -------------------------------------------------- >> >> id : 62894 >> >> text : In contrast to protein-binding inhibition, ... >> >> out_citeFrom : citation#21:460{id:62623,title:Trends in molecular >> medicine,idType:URI,identifier:pmid:15350900,authors:[2],in_citations:#26:9,in_citeFrom:[size=27],in_eCitation:[size=82],in_nCitation:[size=6]} >> v117 >> >> in_supports : network#26:9{...} v5984 >> >> in_nSupport : [size=4] >> >> in_eSupport : [size=2] >> >> >> >> >> >> >> >> >> >> >> >> >> *orientdb {db=ndex}> traverse in_nSupport from #22:6402 >> ----+---------+-----+---------+---------+---------+---------+---------+---------+---------+---------+---------+--------------------------------- >> # |@RID |id >> |in_suppor|in_eSuppo|out_citeF|out_nSupp|out_nCita|out_ndexP|out_repre|in_networ|in_nSuppo|text >> ----+---------+-----+---------+---------+---------+---------+---------+---------+---------+---------+---------+--------------------------------- >> 0 |#22:6402 |62894|#26:9 |[size=2] |#21:460 |null |null >> |null |null |null |[#27:1...|In contrast to protein-binding... >> 1 |#27:12743|62898|null |null |null |[size=2] |[size=2] >> |#14:42061|#24:14391|#26:9 |null |null >> 2 |#27:12744|62900|null |null |null |[size=2] |[size=2] >> |#14:42062|#24:14392|#26:9 |null |null >> ----+---------+-----+---------+---------+---------+---------+---------+---------+---------+---------+---------+--------------------------------- >> 3 item(s) found. Traverse executed in 0.002 sec(s).* >> >> >> >> *Example 2: (includes code example. Problem is more pervasive with >> REMOTE connection)* >> >> >> We are using the 1.7.9-SNAPSHOT version through remote access. In our >> application, all edges are created by the Graph API funcions. The code that >> creates the edges are like this: >> >> * ODocument citationDoc = elementIdCache.get(citationId) >> ; * >> >> * if (citationDoc == null) * >> >> * throw new NdexException ("Citation Id:" + citationId >> + " was not found in elementIdCache.");* >> >> * OrientVertex citationV = graph.getVertex(citationDoc);* >> >> * edgeVertex.addEdge("eCitation", citationV);* >> >> No error or warning when loading data into the db. >> >> Different results when we query the same data from different directions. >> For example >> >> orientdb {db=ndex}> select count(*) from (traverse in_eCitation from >> #21:6) where @class='edge'; >> >> ----+-----+----- >> >> # |@RID |count >> >> ----+-----+----- >> >> 0 |#-2:0|91 >> >> ----+-----+----- >> >> >> 1 item(s) found. Query executed in 0.042 sec(s). >> >> orientdb {db=ndex}> select count(*) from edge where out_eCitation=#21:6 ; >> >> >> ----+-----+----- >> >> # |@RID |count >> >> ----+-----+----- >> >> 0 |#-2:0|94 >> >> ----+-----+----- >> >> >> 1 item(s) found. Query executed in 0.795 sec(s). >> >> >> From one direction we got 91 edges, but from the other direction we got >> 94 edges. >> >> I tried our code to load the same data multiple times with empty >> databases, and the error seems to be consistent. >> >> -- >> >> --- >> 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/d/optout. >> > > > > -- > Best regards, > Andrey Lomakin. > > Orient Technologies > the Company behind OrientDB > > -- 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/d/optout.
