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
