Hi, Looks like an incorrect usage of RidBag by graph functions.
Could you provide a dataset or test case to reproduce it? Best regards, Artem Orobets * Orient Technologiesthe Company behind OrientDB* 2014-05-29 8:34 GMT+03:00 odbuser <[email protected]>: > > I've created the issue: > https://github.com/orientechnologies/orientdb/issues/2405 > > Setting it the configuration to 0 has the same issue. Setting it to 1000 > fixed it but I assume it will not work for size >= 1000. > > OGlobalConfiguration.RID_BAG_EMBEDDED_TO_SBTREEBONSAI_THRESHOLD.setValue( > 1000 ); > > This is a really bad issue but the workaround is to use raw property names > instead of the graph notation. > > in_AtoB.out_AtoC.size() > instead of > > in('AtoB').out('AtoC').size() > > With the understanding that the bad syntax will return null if no C's > exist as opposed to 0 in the graph syntax. > > > On Wednesday, May 28, 2014 4:54:20 PM UTC-4, Lvc@ wrote: > >> Hi, >> this could be related to the "ridBag.embeddedToSbtreeBonsaiThreshold" >> setting that is 80 by default. Please could you repeat the test setting >> this before to open the database? >> >> OGlobalConfiguration.RID_BAG_EMBEDDED_TO_SBTREEBONSAI_THRESHOLD.setValue( >> 1000 ); >> >> or also: >> >> OGlobalConfiguration.RID_BAG_EMBEDDED_TO_SBTREEBONSAI_THRESHOLD.setValue( >> 0 ); >> >> Then please can you open a new issue? >> >> Lvc@ >> >> >> >> On 28 May 2014 22:33, odbuser <[email protected]> wrote: >> >>> OrientDB 1.7 (also failed on snapshots) >>> >>> I have a strange issue with the size() function in an SQL query. It's >>> happening in a very basic database but not in my unit test... and possibly >>> on Windows only. >>> >>> Here's the basic schema: >>> A -AtoB-> B >>> A -AtoC-> C >>> >>> Starting from B, navigate B->A->C and count C. >>> Query: >>> select in('AtoB').out('AtoC').size() from B >>> >>> When the size is greater than at least greater than 67 and definitely 80 >>> and above, the size comes back as 0. If I change the query to: >>> select in_AtoB.out_AtoC.size() from B >>> >>> It always returns the correct count but this is not a good syntax to use >>> since it will return null when no Cs exist not to mention that it's relying >>> on the graph implementation specific properties... >>> >>> I've tried recreating the database with the same issue. I can't share >>> the problematic database and am trying to create a reproducible case but in >>> the meantime, any ideas as to how this could happen? >>> >>> -- >>> >>> --- >>> 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. >>> >> >> -- > > --- > 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. > -- --- 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.
