Rather than "select id, name from document” could you create your view as "select `id`, `name` from document” (or however the back-end system quotes identifiers). Then “id” would still be in lower-case when the JDBC adapter queries the catalog.
> On Aug 24, 2017, at 5:17 AM, Christian Beikov <[email protected]> > wrote: > > My main problem is the row type equality assertion in > org.apache.calcite.plan.SubstitutionVisitor#go(org.apache.calcite.rel.mutable.MutableRel) > > Imagine I have a table "document" with columns "id" and "name". When the > JdbcSchema reads the structure, it gets column names in upper case. Now I > register a materialized view for a query like "select id, name from > document". The materialized table for that view is in my case a view again > defined like "select ... AS `id`, ... AS `name` from ...". > > The row type of my view correctly is "id, name". The row type of the table > "document" is "ID, NAME" because the JdbcSchema gets upper cased names. > Initially, the row type of the query for the materialized view is also > correct, but during the "trim fields" phase the row type gets replaced with > the types from the table. Is this replacement of field types even correct? > > Because of that, the assertion in the substiution visitor fails. What would > be the appropriate solution for this mismatch? > > > 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 >> <[email protected]> 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* >>>> >
