Details
-
Wish
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
Add Rule to check if filter condition is solvable by end application. If part of the filter condition can be solved by end application, then it should get pushed to end application, and remaining part which can not be solved by end application, should get solved by calcite secondarily (i.e. upon fetch remove unwanted data as per filter condition)
Consider an application which can solve only limited operators while filtering, say "=,<,>" and can not solve operator 'LIKE'.
Example, filter condition is "id > 1000 AND name LIKE '%an%'"
we would like to restrict the condition passed to application to "id > 1000" and remaining part "name LIKE '%an%'" should get solved by calcite. (The way it does for csv-adapter)
To replicate the situation, consider test-case testFilter in MongoAdapterTest (org.apache.calcite.adapter.mongodb.MongoAdapterTest) of mongo-adapter.
And modify it like below:
@Test public void testFilter()
{ assertModel(MODEL) .query("select state, city from zips where state = 'CA' AND city LIKE '%E%'") .returnsUnordered("STATE=CA; CITY=LOS ANGELES", "STATE=CA; CITY=BELL GARDENS"); }
Expected output of above query :
STATE=CA; CITY=LOS ANGELES,
STATE=CA; CITY=BELL GARDENS
Expected plan :
EnumerableFilter(condition=[LIKE(CAST(ITEM($0, 'city')):VARCHAR(20), '%E%')])
MongoToEnumerableConverter
MongoProject(STATE=[CAST(ITEM($0, 'state')):VARCHAR(2)], CITY=[CAST(ITEM($0, 'city')):VARCHAR(20)])
MongoFilter(condition=[=(CAST(ITEM($0, 'state')):VARCHAR(2), 'CA')])
MongoTableScan(table=[[mongo_raw, zips]])
Attachments
Issue Links
- relates to
-
CALCITE-3541 Avoid transformations to Enumerable nodes for custom SqlOperators
- Closed