Well my use case is apparently something that isn't supported yet :D

I'd like to have a view instead of a table act as materialization table for a materialized view. The reason is simply that the actual data is in a different non-SQL schema and I need the view to do data conversion.

I noticed that materializations only were looking for tables specifically and adapted it to also lookup views, but now I think I am stuck. Since the view is a LogicalProject, the use of getTable() in RelOptMaterialization won't work. Do you have an idea how I could make that work?


Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 24.08.2017 um 12:57 schrieb Julian Hyde:
Or supply your own TableFactory? I'm not quite sure of your use case.
I've only tested cases where materialized views are "internal",
therefore they work fine with Calcite's default dialect.

On Thu, Aug 24, 2017 at 3:21 AM, Christian Beikov
<christian.bei...@gmail.com> wrote:
Actually, it seems the root cause is that the materialization uses the wrong
configuration.

org.apache.calcite.materialize.MaterializationService.DefaultTableFactory#createTable
creates a new connection with the default configuration that does TO_UPPER.
Would it be ok for it to receive a CalciteConnectionConfig?


Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 24.08.2017 um 11:36 schrieb Christian Beikov:

Seems org.apache.calcite.prepare.CalcitePrepareImpl#prepare2_ misses a
call to
org.apache.calcite.sql.parser.SqlParser.ConfigBuilder#setCaseSensitive to
configure the parser according to the LEX configuration. Is that a bug or
expected?


Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 24.08.2017 um 11:24 schrieb Christian Beikov:

Hey,

I have configured Lex.MYSQL_ANSI but when a query gets parsed, the column
names of select items are "to-upper-cased".

I'm having problems with matching the row types of materialized views and
the source sql because of that. Any idea how to fix that?

--

Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*


Reply via email to