-
Notifications
You must be signed in to change notification settings - Fork 10
Description
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 5Error:
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 sWorkaround
Currently we're using exact matches or fetching all results and filtering client-side, which is inefficient.