Query parsing issue when "in" clause occurs after "or" condition

[RAndrews137]

OrientDB Version, operating system, or hardware.

• v2.0 SNAPSHOT[ ] - .18[ ] .17[ ] .16[ ] .15[ ] .14[ ] .13[ ] .12[ ] .11[ ] .10[ ] .9[ ] .8[ ] .7[ ] .6[ ] .5[ ] .4[ ] .3[ ] .2[ ] .1[ ] .0[ ]
• v2.1 SNAPSHOT[ ] - .16[ ] .15[ ] .14[ ] .13[ ] .12[ ] .11[ ] .10[ ] .9[ ] .8[ ] .7[ ] .6[ ] .5[ ] .4[ ] .3[ ] .2[ ] .1[ ] .0[ ]
• v2.2 SNAPSHOT[X] - .rc1[ ] .beta2[ ] .beta1[ ]

Operating System

• Linux
• MacOSX
• Windows
• Other Unix
• Other, name?

Expected behavior and actual behavior

//Expected: No rows returned, actual rows are returned
select * from V where ( ( (1=1) or (1 in (select 1 from V)) ) and 1=2 )

Steps to reproduce the problem

The following query run from the OrientDB UI is returning rows, even though “and 1=2" should always be false:
select * from V where ( ( (1=1) or (1 in (select 1 from V)) ) and 1=2 )

But if I simply change the order of the "or" condition, then the query correctly honors the "and" condition and returns no rows:
select * from V where ( ( (1 in (select 1 from V)) or (1=1) ) and 1=2 )

It looks like a OrientDB query parsing bug where if you have an “in” after an “or” condition, then the rest of the query is ignored. Note that you can reproduce the problem by using any class, not just V.

[RAndrews137]

I tried to read through the code myself for parsing. Unfortunately, it's pretty complex. Looks like there is a tree construct used for parsing. I am still trying to research why the "or" condition can short-circuit further evaluation.

[RAndrews137]

Latest update is that this is already fixed in the upcoming 3.x. It may or may not get ported back to 2.x version.

[luigidellaquila]

I can confirm, next 3.0 is not affected by this problem.
Unfortunately the solution cannot be ported back because of some intrinsic differences in the query engines, but for sure we will address it in 2.2 (soon, I hope, but it's a tricky issue)

Thanks

Luigi

[RAndrews137]

Just checked using the 2.2.22 version and this issue still occurs.

[luigidellaquila]

Hi @RAndrews137

I just pushed a fix for this on 2.2.x, the fix will be released with 2.2.25

Thanks

Luigi