Planner doesn’t support what you need right now. Can you log a JIRA case please?
You don’t need to sub-class SqlToRelConverter to control its behavior, just
pass in a SqlToRelConverter.Config that says exactly what its behavior should
be. I see that PlannerImpl.rel builds a config but doesn’t allow it to be
customized.
Also change SqlToRelConverter.getSystemFields() so that it gets system fields
from a member variable, populated from Config:
public interface Config {
Function<RelDataTypeFactory, List<RelDataTypeField>> systemFieldsFactory();
}
SqlToRelConverter() {
this.systemFieldList =
ImmutableList.copyOf(config.systemFieldsFactory().apply(typeFactory));
}
Julian
> On Jul 4, 2017, at 12:03 AM, LogSplitter <[email protected]> wrote:
>
> Hi,
>
> I have been trying to get planner to work and it is really close but I seem
> to get into issues due to one special requirement I have where I have to
> remove a system column on 'select *' statements.
>
> Background, we used to remove the special columns by processing through the
> SqlNodeLIst of the validated query and rebuild the select list
> (setSelectList()) with the system column I wanted removed. This approach
> doesn't seem to work in the planner world as I believe I need to do a
> validate after the selectList is modified but the planner model doesn't like
> it when you don't do all steps exactly as it expected (these types of errors
> Exception occurred: cannot move to STATE_3_PARSED from STATE_4_VALIDATED)
>
> I asked in a different thread how to handle the system columns and was told
> to try making my own SqlToRelConverter.getSystemFields() but I could not see
> how I could plug my own SqlToRelConverter into the planner model.
>
> So currently I am scratching my head stuck on an old version of calcite
> wonder which direction I should head. Ideally I would like to use the
> Planner model but need a little pointer of how I get a custom
> SqlToRelConverter.getSystemFields() hooked up.
>
> thanks
>
>
> On 04/22/2017 10:07 AM, Julian Hyde wrote:
>> Have you tried org.apache.calcite.tools.Planner? There are examples in
>> org.apache.calcite.tools.PlannerTest. Barely a mention of SqlValidator, let
>> alone CalciteSchema.
>>
>>
>>> On Apr 21, 2017, at 10:17 PM, LogSplitter <[email protected]> wrote:
>>>
>>> Julian,
>>>
>>> So I am thinking that I am probably missing something here as I seem to
>>> need a CatalogReader to be able to get a SqlValidatorImpl to enable me to
>>> call validate to get the relational algebra. What would be the recommended
>>> way? Pointing me to a sample in the code base should get me on the right
>>> path as I may be way off by the sounds of it, even though it seems to work
>>> very well for what I need in 1.11.
>>>
>>> thanks
>>>
>>>
>>> On 04/21/2017 09:32 PM, Julian Hyde wrote:
>>>> MockCatalogReader was created for testing, but we don’t intend people to
>>>> use it (or a modified version of it) in projects that use Calcite.
>>>>
>>>> CalciteSchema is a private class (the Java class is marked “public” only
>>>> because it is used across several packages) and we don’t intend people to
>>>> use it.
>>>>
>>>> Our intended extension point is Schema. Write your own instance of that
>>>> API to go and get table definitions on demand. You need to write a
>>>> getTableNames() method that returns all table names as a set, but you can
>>>> create the table definitions one at a time when getTable(String name) is
>>>> called.
>>>>
>>>> In https://issues.apache.org/jira/browse/CALCITE-1742
>>>> <https://issues.apache.org/jira/browse/CALCITE-1742> we are discussing
>>>> possibly changing this model, but hopefully in a compatible way.
>>>>
>>>> Julian
>>>>
>>>>
>>>>> On Apr 21, 2017, at 8:19 PM, LogSplitter <[email protected]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am just in the process of updating to the latest version of calcite for
>>>>> my project and have run into an issue and not sure whether I am missing
>>>>> something.
>>>>>
>>>>> I currently use a process based on some of the code around
>>>>> MockCatalogReader to create a catalog and allow my sql to get parsed to
>>>>> relational algebra, which is all I use from the calcite side of things.
>>>>>
>>>>> I was able to dynamically look up metadata previously in the code by
>>>>> having the CatalogReader getTable code lazily load the metadata items as
>>>>> it received request for tables.
>>>>>
>>>>> It seems with the 1.12 code and the requirement to use calciteSchema it
>>>>> expects all the schemas and tables to be available all the time.
>>>>>
>>>>> I am wondering if my lazy load approach is a mistake or if I should work
>>>>> on the calciteSchema interface to allow it to continue with this
>>>>> behaviour.
>>>>>
>>>>> Does anyone have thoughts on if what I am trying to do makes sense.
>>>>>
>>>>> thanks
>>>>>
>>>>>
>
