[
https://issues.apache.org/jira/browse/PHOENIX-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14273911#comment-14273911
]
James Taylor commented on PHOENIX-1578:
---------------------------------------
Thanks for the patch, [~gabriel.reid]. The way we do auto-upgrade is as follows:
- Increment the static constant for MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP
by one
- In ConnectionQueryServicesImpl.init(), which is what gets called on first
connection to a cluster, add a call to addColumnsIfNotExists in the
TableAlreadyExistsException catch block where the SYSTEM.CATALOG table is being
created. For an example call, take a look in the 4.0 branch, but the call just
ends up calling ALTER TABLE to add the new column to the system table and
bumping up the timestamp of it to the new value of
MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP. We do not need to perform the
upgrade if 1) the SYSTEM.CATALOG doesn't exist yet (i.e. a new installation),
or if 2) the SYSTEM.CATALOG has already been upgraded in which case
NewerTableAlreadyExistsException is thrown because a table exists at exactly
MIN_SYSTEM_TABLE_TIMESTAMP (which means, no we didn't find a table after that
timestamp, but you can't create one either because one already exists at or
before that timestamp).
One addition that would be nice IMO to your patch is to provide a config
property that controls the default value of STORE_NULLS. In that way, a new
installation could set that to true and not have to remember to always include
it in CREATE TABLE calls, and existing installations could adopt it also
without calling ALTER TABLE on all existing tables. Perhaps the config property
would just control the value that gets set in PTableImpl by default for
storeNulls?
> Support explicit storage of null values
> ---------------------------------------
>
> Key: PHOENIX-1578
> URL: https://issues.apache.org/jira/browse/PHOENIX-1578
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Gabriel Reid
> Assignee: Gabriel Reid
> Attachments: PHOENIX-1578.patch
>
>
> Null values are currently represented implicitly by a lack of a KeyValue for
> a given field. This is implemented by using an HBase delete to remove cells
> when a given field is set to null via an upsert statement.
> However, this method of setting values to null causes all previous versions
> of the given field to be removed on the next major compaction, which prevents
> doing flashback queries for the given field.
> One workaround for this is to enable KEEP_DELETED_CELLS on the underlying
> HBase table -- however, this means that SQL deletes (i.e. DELETE FROM TABLE)
> will never actually remove the data.
> This ticket is to propose a flag (defined at table level) which specifies
> that null values to be explicitly stored in HBase. This flag should not
> change the behavior of a SQL {{DELETE}} statement, i.e. a SQL {{DELETE}} will
> still cause a record to be permanently deleted (including historical data).
> The use of this flag in combination with KEEP_DELETED_CELLS=false and
> VERSIONS=unlimited will allow Phoenix to provide true row-level versioning.
> Additional background in this mail thread: http://s.apache.org/kwz
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
