Re: Allow Adapter to Participate in the SQL Validation Phase

[Julian Hyde <jh...@apache.org>]

> On Jun 29, 2017, at 2:54 PM, Zain Humayun <zh...@yahoo-inc.com.INVALID> wrote:
> 
> I've been looking into adding the ability for the adapter to register another plug-in for validation, and had a few questions. 
> 
> 1) I see that ModelHandler is responsible for instantiating the plugin classes, and it seems like they're attached to the CalciteConnection object. My question is, where are those plugins actually used? CalcitePrepareImpl? 

What do you mean by “plugin”? 

We have a method AvaticaUtils.instantiatePlugin but it’s just a glorified Class.forName.

> 
> 2) I'm inclined to create a new SqlTypeName called 'COMPLEX' and let the validator dispatch validation on SqlNodes to a plugin class when an expression of type COMPLEX is seen. The adapter would be responsible for assigning the abstract/complex column type COMPLEX in it's TableFactory. Do you see any problems with this approach? Would you suggest a different way of handling things?

I can see that you are trying to create a general mechanism to extend validation, but I wouldn’t use data type as a back door to do it (data type carries a lot of useful semantics, so we don’t want to sacrifice it as a validation hack), nor do I think we’re ready to generalize (we’ve only got one case to generalize from, and the next case where we want to extend validation is unlikely to have the same shape). 

I would be more concrete: add a piece of metadata to a column definition: “onlyAvailableRolledUp: [ true | false ]”. A column flagged as onlyAvailableRolledUp could not be used in a “select” query, only as an argument to an aggregate function. Then add some logic to the validator to validate tables that have such columns.

It is not particularly elegant, but I think that the ability to query data that has “pieces missing” is important. In a sense that’s what we are doing with streams - you cannot query the distant past, only the near past and finite future.

Julian