I've added a JUnit test in the comments to the issue. https://github.com/orientechnologies/orientdb/issues/2405<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Forientechnologies%2Forientdb%2Fissues%2F2405&sa=D&sntz=1&usg=AFQjCNFjfWMKnF_cHDP_kZlP3L0OPFcxgQ>
On Thursday, May 29, 2014 4:07:51 AM UTC-4, Artem Orobets wrote: > > 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] <javascript:>>: > >> >> I've created the issue: >> https://github.com/orientechnologies/orientdb/issues/2405<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Forientechnologies%2Forientdb%2Fissues%2F2405&sa=D&sntz=1&usg=AFQjCNFjfWMKnF_cHDP_kZlP3L0OPFcxgQ> >> >> 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] <javascript:>. >> 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.
