Re: Materialized view case sensitivity problem

I guess it's partly the DBMSes fault, because it either treats identifiers case insensitive or the schema metadata API returns column names in upper case. Not sure if we could do anything about that in the JDBC adapter. I think I will just inspect the JDBC schema before preparing any

Re: Materialized view case sensitivity problem

I apparently had a different problem that lead me to believe the view was the problem. In fact, the actual query was the problem. So i have the query for the materialized view "select id as `id`, name as `name` from document" and the query for the normal view "select cast(_MAP['id'] AS

Re: Materialized view case sensitivity problem

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

Re: Materialized view case sensitivity problem

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

Re: Materialized view case sensitivity problem

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

Re: Materialized view case sensitivity problem

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 wrote: > Actually, it seems

Re: Materialized view case sensitivity problem

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

Re: Materialized view case sensitivity problem

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,

Materialized view case sensitivity problem

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,