Hi Andrey,
I'm still working on a test case, but in contrast to my real application I
can't reproduce the problem.
But as far as I can tell, there IS a problem.
What I found so far is the following:
I have let's say 3 Classes A, B, C, where C is derived from B and B from A.
The index that makes the problems is created on an attribute of A, called
status (an enum, with values like NONE and READY).
The corresponding OrientDB property that I create is of type STRING.
Now I add instances of B and C to the database, let's say 2000 each, 1000
of them with status READY and 1000 with status NONE.
So we have 1000 x B with status NONE, 1000 x B with status READY, 1000 x C
with status NONE and 1000 x C with status READY.
If I execute: {select count(*) from B where status='READY'} it will return
2000 (which is correct).
If I execute: {select count(*) from C where status='READY'} and @class='C'
it will return 1000 (which is correct).
If I execute: {select count(*) from C where status='READY'} it will return
2000 (wrong)!
If I execute: {select * from C where status in ['READY']} it will return NO
row (using IN for a single value of course makes no sense, it's just to
show the problem).
If I execute: {select * from C where status in ['READY'] limit 1001} it
will return ONE row!
It looks like the query of C using IN together with an index returns also
instances of B which are filtered out afterwards?
That would explain why the last query returns one row: because the 1000 x B
+ 1 is the first C row.
If I remove the index or use a query that avoids using the index,
everything works fine (but slower of course).
I know, it looks strange and I can't isolate it in a separate test case,
but maybe you get an idea about why this happens.
Kind regards,
Markus
--
---
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.
