[
https://issues.apache.org/jira/browse/PHOENIX-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687281#comment-16687281
]
Thomas D'Silva commented on PHOENIX-374:
----------------------------------------
When we do a select * or Select CF.* we current only set the column family of
the scan and don't project columns, so I think the scan currently would return
any values stored in dynamic columns. We would need to store the data type of
the dynamic columns at write time, perhaps in the cell as an attribute? I don't
we should modify the table's metadata to include dynamic columns as each row
could a few unique columns. We would have to expose the list of dynamic columns
for each row via the PhoenixResultSet.
FYI [~ckulkarni]
> Enable access to dynamic columns in * or cf.* selection
> -------------------------------------------------------
>
> Key: PHOENIX-374
> URL: https://issues.apache.org/jira/browse/PHOENIX-374
> Project: Phoenix
> Issue Type: New Feature
> Reporter: nicolas maillard
> Priority: Critical
>
> As of recent work we can now read and write columns that are not in the
> schema, AKA dynamic columns. the Select and Upsert allow dynamic columns to
> be specified.
> I think two additions are still needed.
> - Alter dynamicly: In the Upsert and/or Select statement the ability to add
> on the specified dynamic column to schema. Say Upsert into Table (key,
> cf.dynColumn varchar SCHEMAADD) values (..)
> and for select:
> - select key, cf.dynColumn varchar from T would only read
> - select key from T(cf.dynColumn varchar ) would only read and wrtie to
> schema
> - Select a complete column Family: More complex, accessing a whole Column
> Family with all rows known in schema or not.
> select cf.* from T
> today this works for know columns it could be nice to have this for all
> columns of a family in the schema or not. I'm trying right now to extend this
> to schema for unknown columns. However every new row can a lot of very
> different unknowcolumns. The defined ones will be first but the unknown one
> will be appended at the end.
> This means the metadata might need to be updated at every row to account for
> all new columns discovered.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
