[ 
https://issues.apache.org/jira/browse/CALCITE-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889828#comment-17889828
 ] 

Julian Hyde commented on CALCITE-6301:
--------------------------------------

[~oliverlee], I've made an initial pass. I can't quite see how the abstractions 
fit together (e.g. whether the 'remnant' concept is necessary) so it would be 
helpful if you made a series of cleanup commits. First change 
\{{Collections.emptySet}} to {{ImmutableSet.of}} and similar changes to match 
Calcite's house style.

Next let's consider whether a class that contains must-filter-fields, 
bypass-fields, possibly remnants, is simpler to explain than 3 separate fields. 
So, try to make that class. If we do it right, its documentation will be clear 
and its lifecycle will be simple (e.g. all fields immutable). Filter fields 
validation currently occupies lines 4111 through 4190 in the central method of 
the validator - validateSelect - and that is way, way out of balance 
considering the importance of filter fields. With proper abstraction that 
should be 2 - 6 lines, maximum.

> Extend ‘Must-filter’ columns to support a conditional bypass list
> -----------------------------------------------------------------
>
>                 Key: CALCITE-6301
>                 URL: https://issues.apache.org/jira/browse/CALCITE-6301
>             Project: Calcite
>          Issue Type: Improvement
>            Reporter: Oliver Lee
>            Assignee: Oliver Lee
>            Priority: Major
>              Labels: pull-request-available
>
> In CALCITE-6219 we introduced SemanticTable, where tables that implement this 
> interface can define fields to be ‘must-filter’, and a query without those 
> filters in any of its WHERE or HAVING clauses, it will throw a validation 
> error.
>  
> I would like to extend this functionality to support a by-pass list of fields 
> such that if any field from this secondary list is present in a WHERE / 
> HAVING clause, then the must-filter fields can be ignored and will not raise 
> an exception if not filtered on. 
>  
> Ex.
>  
> EMP table specifies the following:
> Must-filter-fields: [EMPNO, DEPTNO]
> Bypass-fields: [ENAME, SALARY]
>  
>  
> SELECT * FROM EMP WHERE EMPNO = 1 and DEPTNO = 2 -> No error
> SELECT * FROM EMP WHERE EMPNO = 1 -> Error
> SELECT * FROM EMP WHERE EMPNO = 1 and ENAME = ’name’ -> No error
> SELECT * FROM EMP WHERE ENAME = ’name’ -> No error
> SELECT * FROM EMP WHERE SALARY > 10 -> No error
>  
>  
>  
> Again, special considerations are for handling 
>  
>  * Joins
>  * CTEs
>  * Subqueries
>  
>  
> And a similar exhaustive suite of tests like the one for CALCITE-6219 should 
> be employed



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to