> On Jun 29, 2017, at 2:54 PM, Zain Humayun <[email protected]> > 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
