[
https://issues.apache.org/jira/browse/PHOENIX-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680224#comment-17680224
]
ASF GitHub Bot commented on PHOENIX-6720:
-----------------------------------------
stoty commented on code in PR #1553:
URL: https://github.com/apache/phoenix/pull/1553#discussion_r1085354653
##########
phoenix-core/src/main/antlr3/PhoenixSQL.g:
##########
@@ -704,19 +707,31 @@ column_defs returns [List<ColumnDef> ret]
: v = column_def {$ret.add(v);} (COMMA v = column_def {$ret.add(v);} )*
;
+column_qualifier_counters returns [Map<String, Integer> ret]
+@init{ret = new HashMap<String,Integer>(); }
+ : k=identifier EQ v=NUMBER {$ret.put(k, Integer.parseInt( v.getText()
));}
+ (COMMA k=identifier EQ v=NUMBER {$ret.put(k, Integer.parseInt(
v.getText() ));} )*
+ ;
+
indexes returns [List<NamedNode> ret]
@init{ret = new ArrayList<NamedNode>(); }
: v = index_name {$ret.add(v);} (COMMA v = index_name {$ret.add(v);} )*
;
column_def returns [ColumnDef ret]
- : c=column_name dt=identifier (LPAREN l=NUMBER (COMMA s=NUMBER)?
RPAREN)? ar=ARRAY? (lsq=LSQUARE (a=NUMBER)? RSQUARE)? (nn=NOT? n=NULL)?
(DEFAULT df=expression)? (pk=PRIMARY KEY (order=ASC|order=DESC)?
rr=ROW_TIMESTAMP?)?
- { $ret = factory.columnDef(c, dt, ar != null || lsq != null, a == null
? null : Integer.parseInt( a.getText() ), nn!=null ? Boolean.FALSE : n!=null ?
Boolean.TRUE : null,
+ : c=column_name dt=identifier (LPAREN l=NUMBER (COMMA s=NUMBER)?
RPAREN)? ar=ARRAY? (lsq=LSQUARE (a=NUMBER)? RSQUARE)? (nn=NOT? n=NULL)?
(DEFAULT df=expression)? ((pk=PRIMARY KEY (order=ASC|order=DESC)?
rr=ROW_TIMESTAMP?)|(COLUMN_QUALIFIER_ID cq=NUMBER))?
Review Comment:
We can use that internal representation independent of the user-facing
format.
I've just verified, that the "COLUMN_QUALIFIER" syscat column always stores
the qualifier, whether we use encoded qualifiers, or unencoded ones.
On the other hand, there is no way to specify the unencoded COLUMN_QUALIFER
directly, so that does not rule out using the integer values here.
We should make sure to use a name that makes it clear this is only for
encoded qualifiers, like
ENCODED_QUALIFER.
> "create table" can't recreate column encoded tables that had columns dropped
> ----------------------------------------------------------------------------
>
> Key: PHOENIX-6720
> URL: https://issues.apache.org/jira/browse/PHOENIX-6720
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 5.2.0, 5.1.3
> Reporter: Istvan Toth
> Assignee: Aron Attila Meszaros
> Priority: Blocker
>
> For column encoded tables,create table generate column qualifier order.
> When moving data between instances, and the original table had some columns
> removed, or swapped around, then the column qualifers in the table are not
> guarenteed to start from the expected value and increase by 1 for each
> column, based on the ordering of columns.
> This means that when we load a data table via HBase (i.e from a snaphsot),
> and then execute the DDL created by the show create table, or by other means,
> the column_qualifiers on the new table are going to point to the wrong Hbase
> cell.
> We need to accept and use COLUMN_QUALIFIER properties for columns, and
> include them in in the show create table output for column encoded tables.
> We also need to accept and generate QUALIFIER_COUNTER for the tables.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
