Affects Version/s: None
Fix Version/s: 0.4.0
One approach is to implement DrillSqlOperatorTable which extends Optiq's ReflectiveSqlOperatorTable. Optiq has a notion of chained operator table with which we can simply add our specific operator table (DrillSqlOperatorTable) to its existing operator tables such that Optiq recognizes all functions defined in DrillSqlOperatorTable.
The main requirement of this task is to not have yet another set of declaration of functions, we want to automatically declare Drill's custom functions in a format understood by Optiq.
Below is the task breakdown:
1. Registering of drill functions should take place before we register Optiq's functions. (This can be done as part of the "thinning out the JDBC client" task)
2. Once we have a set of registered functions in Drill, we need to go through them and define them using Optiq's syntax (using SqlFunction() for example)
3. Plugin DrillSqlOperatorTable into Optiq's ChainedSqlOperatorTable.
One minor challenge might be to get around the way ReflectiveSqlOperatorTable works. ReflectiveSqlOperatorTable gets all the fields defined in the derived class (all fields in the derived class are operators or functions that need to be registered, eg: SqlStdOperatorTable) and adds it to a Map which it uses later to verify if the function/ operator exists. We need to come up with a way to automatically define these fields so that ReflectiveSqlOperatorTable picks them up.
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|185d 20h 10m||1||Mehant Baid||19/May/14 04:10|
|Workflow||no-reopen-closed, patch-avail, testing [ 12859984 ]||Drill workflow [ 12933674 ]|
|Fix Version/s||0.4.0 [ 12324963 ]|
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Resolution||Fixed [ 1 ]|
|Field||Original Value||New Value|
|Workflow||no-reopen-closed, patch-avail [ 12826290 ]||no-reopen-closed, patch-avail, testing [ 12859984 ]|