[
https://issues.apache.org/jira/browse/TINKERPOP-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701213#comment-17701213
]
Zeyang Zhuang commented on TINKERPOP-2895:
------------------------------------------
Dear Stephen, following your instruction, I can still keep triggering this
intersection inconsistency. In fact, by randomly matching patterns and
calculating intersections on a generated graph, I met more bugs than the
following example.
*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.V().in('el2','el1').both('el1')` returns `[0, 11, 19, 4, 6]`.
2. `g.V().both('el2','el1')` returns `[0, 11, 13, 19, 4, 6]`.
3.
`g.V().match(__.as('a').in('el2','el1').both('el1'),__.as('a').filter(both('el2','el1'))).select('a')`
returns `[0, 11, 13, 19, 4]`.
We calculate the intersection result set of Q1 and Q2, which is `[0, 11, 19, 4,
6]`.
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('vl1').property('vp3','true').property(T.id,0)
g.addV('vl2').property('vp0','-1270611045').property(T.id,2)
g.addV('vl1').property('vp3','true').property(T.id,4)
g.addV('vl0').property('vp2',''nw)0Y'').property(T.id,6)
g.addV('vl2').property('vp0','-1270611045').property('vp2',''~kK4?'').property(T.id,8)
g.addV('vl1').property('vp3','false').property(T.id,11)
g.addV('vl1').property('vp3','false').property(T.id,13)
g.addV('vl2').property('vp2',''qrΛO|'').property(T.id,15)
g.addV('vl2').property('vp2',''qrΛO|'').property(T.id,17)
g.addV('vl1').property('vp3','false').property(T.id,19)
Edge:
g.V(11).as('11').V(0).as('0').addE('el2').from('11').to('0')
g.V(11).as('11').V(13).as('13').addE('el0').from('11').to('13')
g.V(11).as('11').V(19).as('19').addE('el0').from('11').to('19')
g.V(19).as('19').V(0).as('0').addE('el2').from('19').to('0')
g.V(13).as('13').V(11).as('11').addE('el2').from('13').to('11')
g.V(0).as('0').V(6).as('6').addE('el1').from('0').to('6')
g.V(11).as('11').V(6).as('6').addE('el1').from('11').to('6')
g.V(13).as('13').V(0).as('0').addE('el0').from('13').to('0')
g.V(4).as('4').V(11).as('11').addE('el2').from('4').to('11')
g.V(4).as('4').V(13).as('13').addE('el2').from('4').to('13')
g.V(19).as('19').V(6).as('6').addE('el1').from('19').to('6')
g.V(0).as('0').V(11).as('11').addE('el2').from('0').to('11')
g.V(13).as('13').V(4).as('4').addE('el2').from('13').to('4')
g.V(4).as('4').V(6).as('6').addE('el1').from('4').to('6')
g.V(11).as('11').V(0).as('0').addE('el0').from('11').to('0')
g.V(0).as('0').V(19).as('19').addE('el2').from('0').to('19')
g.V(19).as('19').V(11).as('11').addE('el2').from('19').to('11')
g.V(13).as('13').V(19).as('19').addE('el2').from('13').to('19')
g.V(4).as('4').V(19).as('19').addE('el0').from('4').to('19')
g.V(0).as('0').V(11).as('11').addE('el0').from('0').to('11')
```
> 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)
