[
https://issues.apache.org/jira/browse/TINKERPOP-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701214#comment-17701214
]
Zeyang Zhuang commented on TINKERPOP-2895:
------------------------------------------
In case the matching *edges* logic is different from matching nodes. I provide
another example for edges here.
*Expected behavior:*
We generate graph schema and data based on random strings and values. Here is
one of our examples that triggered the bug.
1. `g.E().and(__.order().by(desc)).hasLabel('el0','el1','el3')` returns `[20,
23, 26, 27, 29, 30, 31, 32, 33, 35, 36, 37, 38, 39]`.
2. `g.E().outV().inE('el0','el2')` returns `[21, 22, 24, 25, 28, 29, 30, 31,
32, 34, 37]`.
3.
`g.E().match(__.as('a').and(__.order().by(desc)).hasLabel('el0','el1','el3'),__.as('a').filter(outV().inE('el0','el2'))).select('a')`
returns `[27, 29, 30, 31, 32, 33, 35, 36, 37, 38]`.
We calculate the intersection result set of Q1 and Q2, which is `[29, 30, 31,
32, 37]`.
The intersection result set doesn't equal to Q3 result set.
*Actual behavior:*
The intersection result set should equal to Q3 result set. We did trigger some
cases conform to this requirement, but still there're some cases that violate
this constraint.
*Steps to reproduce:*
Create data
```
Vertex:
g.addV('vl2').property('vp0','true').property(T.id,0)
g.addV('vl2').property('vp0','true').property(T.id,2)
g.addV('vl1').property('vp0','false').property(T.id,4)
g.addV('vl0').property('vp0','false').property(T.id,6)
g.addV('vl1').property('vp0','false').property(T.id,8)
g.addV('vl0').property('vp0','true').property(T.id,10)
g.addV('vl0').property('vp0','true').property(T.id,12)
g.addV('vl0').property('vp0','false').property(T.id,14)
g.addV('vl1').property('vp0','true').property(T.id,16)
g.addV('vl2').property('vp0','false').property(T.id,18)
Edge:
g.V(14).as('14').V(8).as('8').addE('el1').from('14').to('8')
g.V(2).as('2').V(12).as('12').addE('el2').from('2').to('12')
g.V(2).as('2').V(10).as('10').addE('el2').from('2').to('10')
g.V(6).as('6').V(8).as('8').addE('el1').from('6').to('8')
g.V(0).as('0').V(6).as('6').addE('el2').from('0').to('6')
g.V(0).as('0').V(12).as('12').addE('el2').from('0').to('12')
g.V(6).as('6').V(4).as('4').addE('el1').from('6').to('4')
g.V(16).as('16').V(2).as('2').addE('el3').from('16').to('2')
g.V(18).as('18').V(12).as('12').addE('el2').from('18').to('12')
g.V(2).as('2').V(18).as('18').addE('el0').from('2').to('18')
g.V(0).as('0').V(2).as('2').addE('el0').from('0').to('2')
g.V(18).as('18').V(0).as('0').addE('el0').from('18').to('0')
g.V(18).as('18').V(18).as('18').addE('el0').from('18').to('18')
g.V(8).as('8').V(0).as('0').addE('el3').from('8').to('0')
g.V(2).as('2').V(14).as('14').addE('el2').from('2').to('14')
g.V(16).as('16').V(0).as('0').addE('el3').from('16').to('0')
g.V(4).as('4').V(0).as('0').addE('el3').from('4').to('0')
g.V(18).as('18').V(2).as('2').addE('el0').from('18').to('2')
g.V(4).as('4').V(2).as('2').addE('el3').from('4').to('2')
g.V(14).as('14').V(4).as('4').addE('el1').from('14').to('4')
```
> Merged query using logical operator AND returns false results
> -------------------------------------------------------------
>
> Key: TINKERPOP-2895
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2895
> Project: TinkerPop
> Issue Type: Bug
> Components: driver, server
> Affects Versions: 3.6.2
> Environment: - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
> Reporter: Zeyang Zhuang
> Priority: Major
>
> We discovered a bug that Merged query using logical operator AND returns
> false results.
> - TinkerGraph Version: 3.6.2
> - Operating system: macOS 13.2.1
> - API/Driver: Java
> *Expected behavior:*
> We construct the following scenario: we randomly generate two queries Q1, Q2,
> and merge these two queries using AND logical operator into a new query Q3.
> Based on the AND calculation. The Q3 query result set should be the
> intersection of result sets from Q1 and Q2.
> We generate graph schema and data based on random strings and values. Here is
> one of our examples that triggered the bug.
> 1) `g.V().outE('el0','el2').bothV()` returns `[0, 0, 11, 11, 13, 13, 13, 13,
> 18, 18, 18, 18, 18, 2, 2, 2, 2, 2, 2, 2, 6, 6, 6, 6, 6, 8, 8, 8]`
> 2) `g.V().hasLabel('vl1','vl0')` returns `[16, 18, 2, 21, 4, 6, 8]`
> 3) `g.V().and(outE('el0','el2').bothV(),hasLabel('vl1','vl0'))` returns `[18,
> 2, 6]`.
> We calculate the intersection result set of Q1 and Q2, which is `[18, 2, 6,
> 8]`.
> The intersection result set doesn't equal to Q3 result set.
> *Actual behavior:*
> The intersection result set should equal to Q3 result set. We did trigger
> some cases conform to this requirement, but still there're some cases that
> violate this constraint.
> *Steps to reproduce:*
> We create a graph with 10 nodes and 20 edges. We 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 data
> ```
> Vertex:
> g.addV('vl2').property('vp2','0.11229777').property(T.id,0)
> g.addV('vl1').property('vp1','0.7532909965461835').property(T.id,2)
> g.addV('vl0').property('vp6','-882633195435277600').property(T.id,4)
> g.addV('vl1').property('vp4','7665355125606600882').property(T.id,6)
> g.addV('vl1').property('vp1','0.7532909965461835').property('vp4','3838824259062394782').property(T.id,8)
> g.addV('vl2').property('vp4','6730135576265295973').property(T.id,11)
> g.addV('vl2').property('vp3','-6896539503167143038').property('vp4','-2940639995931981142').property(T.id,13)
> g.addV('vl0').property('vp6','-2552831883676257311').property(T.id,16)
> g.addV('vl1').property('vp1','0.4100010612879974').property('vp4','-2768293334048120500').property(T.id,18)
> g.addV('vl0').property('vp6','8251747935808021903').property(T.id,21)
> Edge:
> g.V(0).as('0').V(2).as('2').addE('el1').from('0').to('2')
> g.V(8).as('8').V(6).as('6').addE('el0').from('8').to('6')
> g.V(0).as('0').V(18).as('18').addE('el1').from('0').to('18')
> g.V(6).as('6').V(13).as('13').addE('el2').from('6').to('13')
> g.V(18).as('18').V(2).as('2').addE('el0').from('18').to('2')
> g.V(18).as('18').V(0).as('0').addE('el2').from('18').to('0')
> g.V(6).as('6').V(18).as('18').addE('el0').from('6').to('18')
> g.V(2).as('2').V(11).as('11').addE('el2').from('2').to('11')
> g.V(8).as('8').V(13).as('13').addE('el2').from('8').to('13')
> g.V(11).as('11').V(8).as('8').addE('el1').from('11').to('8')
> g.V(18).as('18').V(13).as('13').addE('el2').from('18').to('13')
> g.V(8).as('8').V(0).as('0').addE('el2').from('8').to('0')
> g.V(6).as('6').V(11).as('11').addE('el2').from('6').to('11')
> g.V(11).as('11').V(18).as('18').addE('el1').from('11').to('18')
> g.V(2).as('2').V(6).as('6').addE('el0').from('2').to('6')
> g.V(13).as('13').V(6).as('6').addE('el1').from('13').to('6')
> g.V(0).as('0').V(6).as('6').addE('el1').from('0').to('6')
> g.V(2).as('2').V(13).as('13').addE('el2').from('2').to('13')
> g.V(2).as('2').V(18).as('18').addE('el0').from('2').to('18')
> g.V(2).as('2').V(2).as('2').addE('el0').from('2').to('2')
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
