Thanks for the info about the overridable schema methods. I'll take a look at those and see if they're a fit for what i'm trying to achieve. You mentioned that we should allow adapters to include more kinds of plugins, and I definitely agree. I've created something called a "RelValidationRule" that lets adapters validate relational expressions (as opposed to transforming them), so that adapters have a chance to participate in validation.
I was wondering if there was already a "plugin" similar to this in calcite (that is not already exposed to adapters). If not, do you think adding this new kind of rule is the proper way of letting adapters partake in the validation? Zain. On Monday, June 26, 2017, 5:16:29 PM PDT, Julian Hyde <[email protected]> wrote: It sounds as if you need to define new SqlOperator instances and get them into the SqlOperatorTable used by the validator. If you override the Schema.getFunctionNames() and Schema.getFunctions(String name) methods you should be able to declare additional user-defined functions (regular functions, table functions, and even table macros, which are a generalization of views). I don’t recall whether these have to be user-defined functions based on a simple Java class, or whether we allow SqlOperator with more complex rules for validation and code-generation. That said, there are many kinds of plug-ins that you can implement to change the behavior of the validator (and other parts of the query preparation process such as planning). But only a few of them (mainly schema, table, and planning rules) are currently part of the loose bundling concept we call an “adapter”. We should allow adapters to include more kinds of plug-ins. Julian > On Jun 20, 2017, at 2:02 PM, Zain Humayun <[email protected]> > wrote: > > Hi, > > I'm looking into adding additional functionality to the Druid adapter, and > will need to somehow change the behaviour of calcite's validation logic > (either at the adapter level, or the core level). I was wondering if there > was an existing way for an adapter to participate in SQL validation > (specifically function type checking). As far as I can tell, the only part of > an adapter that calcite is aware of during validation are the table factory > classes, which end up returning a table that are stored inside of a schema. > > If such functionality does not currently exist, what would be the best way to > approach this? Essentially i'm trying to do type checking on aggregate > functions with the help of information stored inside DruidQuery/DruidTable. > At the moment I'm thinking the best way might be to add another JDBC string > parameter specifying a class that can assist calcite in validation. > > Another approach might be to push the logic into the adapter entirely (as a > rule for example) and then throw an exception when something fails > validation. This approach is more hacky, but it might also be feasible. > > If anyone has experience in implementing something similar to this and/or > calcite's validation code in general i'd love to hear your thoughts. > > Thanks, > Zain.
