Apache Drill
  1. Apache Drill
  2. DRILL-298

Extend Optiq's SqlOperatorTable to support Drill's custom functions

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.4.0
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Mehant Baid added a comment -

        Merged as b2263f9bb307d0119317418de183d0e2822757e7

        Show
        Mehant Baid added a comment - Merged as b2263f9bb307d0119317418de183d0e2822757e7
        Hide
        Julian Hyde added a comment -

        Mehant, you've nailed it. If you want to modify the behavior of SqlOperatorTable and ReflectiveOperatorTable, say via options added to their constructors, I am happy to work with you on that.

        Consider using SqlOperatorTest (or a sub-class) in Drill's test suite. It's a powerful test because it fires tests at a "tester" that the sub-class can override. So you can define a test for an operator once and run it in many environments (validation only, code-generation only, runtime environment a, runtime environment b).

        Show
        Julian Hyde added a comment - Mehant, you've nailed it. If you want to modify the behavior of SqlOperatorTable and ReflectiveOperatorTable, say via options added to their constructors, I am happy to work with you on that. Consider using SqlOperatorTest (or a sub-class) in Drill's test suite. It's a powerful test because it fires tests at a "tester" that the sub-class can override. So you can define a test for an operator once and run it in many environments (validation only, code-generation only, runtime environment a, runtime environment b).

          People

          • Assignee:
            Mehant Baid
            Reporter:
            Mehant Baid
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development