[
https://issues.apache.org/jira/browse/TINKERPOP-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701116#comment-17701116
]
Stephen Mallette commented on TINKERPOP-2895:
---------------------------------------------
I still don't see a problem. Your expected intersection is not correct. you
assume that {{match()}} is going to intersect the results of traversals 1 and 2
as you have written them, but {{match()}} actually intersecting the result of:
{code}
1. g.V().hasNot('vp2')
2. g.V().filter(both('e1').has('vp4'))
{code}
{{match()}} is a filtering step. your query is really saying: "find me all
vertices that do not have a property of 'vp2' and that have at least one edge
to a vertex with a property of 'vp4'". Please recalculate your intersection
using the two queries above and I think you'll find that it {{match()}} is
working as expected.
Also, could you please tell me where these examples are coming from? are they
generated? do you have some tool for doing this? Is this work in relation to a
graph database implementation you are working on?
> 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)
