False alarms about GraphGenie

[ljhhuxiaoba]

I ran GraphGenie for 1 hour on Redisgraph and found some problems in some test case pairs:
First:
base query:OPTIONAL MATCH (iqdwmbdq:Movie)-[]->() WHERE iqdwmbdq IS NOT NULL RETURN count(iqdwmbdq)
test query:OPTIONAL MATCH (iqdwmbdq:Movie)-[]->() WHERE iqdwmbdq IS NOT NULL RETURN count()
Second:
base query:OPTIONAL MATCH ()-[]->()-[]->()-[..1]->()<-[]-()<-[]-() WHERE True RETURN count(1) ORDER BY NULL
test query:MATCH ()-[]->()-[]->()-[*..1]->()<-[]-()<-[]-() WHERE True WITH * WHERE True AND True AND True RETURN count(1) ORDER BY NULL

And I think these two are false alarms because "count(iqdwmbdq) " is not equivalent to "count(*)" and "OPTIONAL MATCH" is not equivalent to "MATCH".But it says that " our test oracle only identified bugs caused by semantic discrepancies,
ensuring that GraphGenie only reports true logic bugs." in initial paper, so I wonder if these are my misjudgment.

Looking forward to your reply.

[YuanchengJiang]

Hi @ljhhuxiaoba, technically the oracle of GraphGenie has no false alarm like differential testing (e.g., same bug exists in multiple db instances). However, the implementation could have false alarms, which means GraphGenie could have an inaccurate transformation rule that generates inequivalent queries (also one valid transformation might be incorrect in another graph db). I'd be happy to fix them.

[ljhhuxiaoba]

Thank you for your response. I am using GraphGenie as baseline in my paper so please keep me informed if there is an updated version, thanks.

[YuanchengJiang]

@ljhhuxiaoba wondering why OPTIONAL MATCH (iqdwmbdq:Movie)-[]->() WHERE iqdwmbdq IS NOT NULL RETURN count(iqdwmbdq) is semantically different from OPTIONAL MATCH (iqdwmbdq:Movie)-[]->() WHERE iqdwmbdq IS NOT NULL RETURN count()? Could you illustrate more on it?

[stupalpa]

@YuanchengJiang. Hello, I'm also using GraphGenie as our baseline. I think this might be because Cypher's count() function handles different parameters differently. Neo4j's official documentation describes the return value of count() like this neo4j:

count(*) includes rows returning null.
count(input) ignores null values.
count(null) returns 0.

Therefore, count(iqdwmbdq) and count(*) shouldn't be equivalent. However, in this example above, the WHERE iqdwmbdq IS NOT NULL clause explicitly filters out null values. As a result, I think they should be equivalent in this specific case.

[YuanchengJiang]

@stupalpa thank you, that makes sense. I think GraphGenie can be patched to have more accurate query equivalence considering null counting.

• patch count() equivalence considering null