Summary
The Cypher parser currently doesn't support string comparison operators like CONTAINS, STARTS WITH, and ENDS WITH. These are commonly used Cypher operators for filtering nodes/relationships by partial string matching.
Current Behavior
Queries using string operators fail with a parsing error:
MATCH (s:Symbol) WHERE s.name CONTAINS 'Auth' RETURN s.name LIMIT 5
Error:
Cypher query error: Failed to parse Cypher query: Cypher parse error at position 0:
Failed to parse Cypher query: Parsing Error: Error { input: "WHERE s.name CONTAINS 'Auth' RETURN s.name LIMIT 5", code: Tag }
Expected Behavior
String comparison operators should be parsed and translated to SQL equivalents:
| Cypher |
SQL Equivalent |
CONTAINS 'foo' |
LIKE '%foo%' |
STARTS WITH 'foo' |
LIKE 'foo%' |
ENDS WITH 'foo' |
LIKE '%foo' |
Technical Context
Looking at src/parser.rs, the comparison_operator function (lines 356-366) only handles:
And comparison_expression handles:
IN [...]
IS NULL, IS NOT NULL
String operators would need to be added as additional branches, likely with a new StringOperator enum or extending ComparisonOperator.
Use Case
We're using lance-graph for a code analysis tool where users query a knowledge graph of code symbols. Partial name matching is essential:
-- Find all authentication-related functions
MATCH (s:Symbol) WHERE s.name CONTAINS 'auth' RETURN s
-- Find all test files
MATCH (f:File) WHERE f.path ENDS WITH '.test.ts' RETURN f
-- Find functions starting with 'handle'
MATCH (s:Symbol) WHERE s.name STARTS WITH 'handle' RETURN s
Workaround
Currently we're using exact matches or fetching all results and filtering client-side, which is inefficient.
References
Summary
The Cypher parser currently doesn't support string comparison operators like
CONTAINS,STARTS WITH, andENDS WITH. These are commonly used Cypher operators for filtering nodes/relationships by partial string matching.Current Behavior
Queries using string operators fail with a parsing error:
Error:
Expected Behavior
String comparison operators should be parsed and translated to SQL equivalents:
CONTAINS 'foo'LIKE '%foo%'STARTS WITH 'foo'LIKE 'foo%'ENDS WITH 'foo'LIKE '%foo'Technical Context
Looking at
src/parser.rs, thecomparison_operatorfunction (lines 356-366) only handles:=,<>,!=<,>,<=,>=And
comparison_expressionhandles:IN [...]IS NULL,IS NOT NULLString operators would need to be added as additional branches, likely with a new
StringOperatorenum or extendingComparisonOperator.Use Case
We're using lance-graph for a code analysis tool where users query a knowledge graph of code symbols. Partial name matching is essential:
Workaround
Currently we're using exact matches or fetching all results and filtering client-side, which is inefficient.
References