[
https://issues.apache.org/jira/browse/FLINK-21532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lsw_aka_laplace updated FLINK-21532:
------------------------------------
Description:
For now, both legacy Table/SQL API and implementation and current Table/SQL API
and implementation are case sensitive when it comes to the key of table
properties. Though it is highly recommended to be full of low case, key in
upper case still works well.
But the following case upon current code seems a little misleading..
Given a Ddl sql:
"""
create table a (f string) with ('K1' = 'xxx')
"""
The property of corresponding `CatalogTableImpl` is Map(K1->xxx).
After calling `CatalogTableImpl#toProperties` and then
`CatalogTableImpl#fromProperties`, there comes a `CatalogTableImpl` with
properity:Map(k1->xxx). The letter in upper case has been converted into low
case.
After reading code, the reason seems that the two method mentioned above
normalize key by default and can not be configured.
As far as I'm concerned, There is an easy way that just ` DescriptorProperties
descriptorProperties = new DescriptorProperties(false)`, when means not to
normalize key to low case.
While, for the fear that this should break some underlying rules and cause some
unexpected incompatibility. This part shall be under well discussed.
What's more, a better alternate way is welcomed~
was:
For now, both legacy Table/SQL API and implementation and current Table/SQL API
and implementation are case sensitive when it comes to the key of table
properties. Though it is highly recommended to be full of low case, key in
upper case still works well.
But the following case upon current code seems a little misleading..
Given a Ddl sql:
"""
create table a (f string) with ('K1' = 'xxx')
"""
The property of corresponding `CatalogTableImpl` is Map(K1->xxx).
After calling `CatalogTableImpl#toProperties` and then
`CatalogTableImpl#fromProperties`, there comes a `CatalogTableImpl` with
properity:Map(k1->xxx). The letter in upper case has been converted into low
case.
After reading code, the reason seems that the two method mentioned above
normalize key by default and can not be configured.
As far as I'm concerned, There is an easy way that just ` DescriptorProperties
descriptorProperties = new DescriptorProperties(false)`, when means not to
normalize key to low case.
While, for the fear that this should break some underlying rules and cause some
unexpected incompatibility. This part shall be under well discussed.
> Make CatalogTableImpl#toProperties and CatalogTableImpl#fromProperties case
> sensitive
> -------------------------------------------------------------------------------------
>
> Key: FLINK-21532
> URL: https://issues.apache.org/jira/browse/FLINK-21532
> Project: Flink
> Issue Type: Improvement
> Components: Table SQL / API
> Reporter: Lsw_aka_laplace
> Priority: Major
>
> For now, both legacy Table/SQL API and implementation and current Table/SQL
> API and implementation are case sensitive when it comes to the key of table
> properties. Though it is highly recommended to be full of low case, key in
> upper case still works well.
> But the following case upon current code seems a little misleading..
> Given a Ddl sql:
> """
> create table a (f string) with ('K1' = 'xxx')
> """
> The property of corresponding `CatalogTableImpl` is Map(K1->xxx).
> After calling `CatalogTableImpl#toProperties` and then
> `CatalogTableImpl#fromProperties`, there comes a `CatalogTableImpl` with
> properity:Map(k1->xxx). The letter in upper case has been converted into low
> case.
>
> After reading code, the reason seems that the two method mentioned above
> normalize key by default and can not be configured.
>
> As far as I'm concerned, There is an easy way that just `
> DescriptorProperties descriptorProperties = new DescriptorProperties(false)`,
> when means not to normalize key to low case.
>
> While, for the fear that this should break some underlying rules and cause
> some unexpected incompatibility. This part shall be under well discussed.
> What's more, a better alternate way is welcomed~
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
