You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We discovered a bug that Query partitioning return false results.
OrientDB version: 3.2.14
Operating system: macOS 13.2.1
API/Driver: Java
Expected behavior:
We construct the following scenario: we split a given query Q into three derived sub-queries, in which the predicate is evaluated to TRUE, FALSE, and IS NULL, respectively. The union of the three derived result sets should be equal to the result set of query Q.
We generate graph schema and data based on random strings and values. Here is one of our examples that triggered the bug.
g.V().has('vp0',0.3792261648797388).hasNot('vp0').count() returns 0
We can see that sub-queries 2, 3, 4 results: 1 + 0 + 0 != 0
Actual behavior:
The sum of sub-queries 2, 3, 4 results: 1 + 0 + 0 != 0
Steps to reproduce:
We are developing a fuzzing technique to test your GraphDB. We create a graph with 10 nodes and 20 edges. And try to make it clear to reproduce the bugs, hope to not cause much inconvenience to your reviewing, but we believe the problem does exist.
Following the following graph data generation query, we can reproduce the bugs:
We discovered a bug that Query partitioning return false results.
OrientDB version: 3.2.14
Operating system: macOS 13.2.1
API/Driver: Java
Expected behavior:
We construct the following scenario: we split a given query Q into three derived sub-queries, in which the predicate is evaluated to TRUE, FALSE, and IS NULL, respectively. The union of the three derived result sets should be equal to the result set of query Q.
We generate graph schema and data based on random strings and values. Here is one of our examples that triggered the bug.
g.V().has('vp0',0.3792261648797388).count()
returns 0g.V().has('vp0',0.3792261648797388).has('vp0', outside(0.8780335669045662,0.18019845106122412)).count()
returns 1g.V().has('vp0',0.3792261648797388).has('vp0', not(outside(0.8780335669045662,0.18019845106122412))).count()
returns 0g.V().has('vp0',0.3792261648797388).hasNot('vp0').count()
returns 0We can see that sub-queries 2, 3, 4 results: 1 + 0 + 0 != 0
Actual behavior:
The sum of sub-queries 2, 3, 4 results: 1 + 0 + 0 != 0
Steps to reproduce:
We are developing a fuzzing technique to test your GraphDB. We create a graph with 10 nodes and 20 edges. And try to make it clear to reproduce the bugs, hope to not cause much inconvenience to your reviewing, but we believe the problem does exist.
Following the following graph data generation query, we can reproduce the bugs:
Create schema
The text was updated successfully, but these errors were encountered: