Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Mon, 4 Dec 2017 12:56:00 +0000 (UTC)
From: "Marcin Januszkiewicz (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13122569.1512392113000.377994.1512392160149@Atlassian.JIRA>
In-Reply-To: <JIRA.13122569.1512392113000@Atlassian.JIRA>
References: <JIRA.13122569.1512392113000@Atlassian.JIRA> <JIRA.13122569.1512392113195@jira-lw-us.apache.org>
Subject: [jira] [Created] (PHOENIX-4433) Phoenix passes around String
 representations of columns that cannot be correctly parsed.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 04 Dec 2017 12:56:06 -0000

Marcin Januszkiewicz created PHOENIX-4433:
---------------------------------------------

             Summary: Phoenix passes around String representations of columns that cannot be correctly parsed.
                 Key: PHOENIX-4433
                 URL: https://issues.apache.org/jira/browse/PHOENIX-4433
             Project: Phoenix
          Issue Type: Bug
            Reporter: Marcin Januszkiewicz


I've been doing some investigating into PHOENIX-3696.
I've found that many Phoenix utility methods operate on string representations on column names while making incorrect assumptions about the shape of the column name,
For example, the method ColumnInfo.getDisplayName assumes that if a period exists in a column name, then it must be a column family separator.
SchemaUtil.generateColumnInfo will separate column family from column names with a period, but won't escape them, making it impossible to parse back to the proper column name.
The PhoenixRuntime.getColumnInfo will throw an Exception if there is more than one period in the column name, even if properly escaped.
This pattern is present within the public API of Phoenix, so I don't think it can be change in a backward-incompatible way.
I think the proper way of fixing this is to introduce a new column identifier class that can be passed around instead, and only using strings when we need a serialized value.
Then we could deprecate the string-based methods.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)