Unfortunately this isn't fully fixed. I have a query that performs this
type of size() and I though it was fully fixed when the size() <= 80 but
now I have several rows that return 0. I do not have a reproducible case
except for a few live database which I can't share. I'll continue to try
and create a test case but if someone could look at other possibilities as
to why this is still happening, that would be great.
Note, it's not broken at the
OGlobalConfiguration.RID_BAG_EMBEDDED_TO_SBTREEBONSAI_THRESHOLD
anymore. For example in one case, about 40 vertices are returned and about
10 or so return 0 with this syntax:
in('AtoB').out('AtoC').size()
but correctly with:
in_AtoB.out_AtoC.size()
The sizes range from about 100 to 200 and all of the ones that fail are
between 120 and 130 but not exclusively so.
On Friday, May 30, 2014 11:50:11 AM UTC-4, odbuser wrote:
>
> I just verified the fix in the 1.7.1-SNAPSHOT build from git. Thanks.
>
> On Friday, May 30, 2014 2:48:37 AM UTC-4, Artem Orobets wrote:
>>
>> Thanks, I'll take a look.
>>
>> Best regards,
>> Artem Orobets
>>
>> *Orient Technologies the Company behind OrientDB*
>>
>>
>> 2014-05-30 7:11 GMT+03:00 odbuser <[email protected]>:
>>
>>> I've updated the issue with a slightly simpler use case. It only needed
>>> A->B to illustrate.
>>>
>>>
>>> On Thursday, May 29, 2014 11:36:39 AM UTC-4, odbuser wrote:
>>>>
>>>> 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]>:
>>>>>
>>>>>>
>>>>>> 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].
>>>>>> 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.
