What is the original purpose of RelBuilder? Is it for supporting building languages other than SQL as front end? If it is, I would vote for adding ability to do the validation at the relnode level instead of SQLNode.
-JD > On Jun 27, 2017, at 9:06 PM, Julian Hyde <[email protected]> wrote: > > I'm curious why you want to validate relational expressions (RelNode). > Most projects that use Calcite use SQL as the front end, and they > validate the SQL parse tree (SqlNode). If the parse tree is valid then > the relational algebra will also be valid. > > But anyway, I could see a use for RelValidationRule if, say, people > were creating queries using RelBuilder, or they wanted extra checks on > what their RelOptRules were doing. > > As for including these in an adapter. I would see an adapter as a > bundle of classes implementing a variety of plugin-in interfaces, > perhaps packaged into a JAR with a manifest containing the list of > classes that implement each interface (maybe something similar to > META-INF/services/java.sql.Driver; see ServiceLoader [1]). We could > add new plugin types as we go. > > Julian > > [1] https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html > > On Mon, Jun 26, 2017 at 5:49 PM, Zain Humayun > <[email protected]> wrote: >> >> 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.
