[
https://issues.apache.org/jira/browse/PHOENIX-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278844#comment-14278844
]
Gabriel Reid commented on PHOENIX-1578:
---------------------------------------
Ok, I'll give it a go to bring it to the 3.x branch as well -- note to self,
also include the change in PHOENIX-1586.
> 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
> Fix For: 5.0.0, 4.3
>
> Attachments: PHOENIX-1578-docs.patch, PHOENIX-1578.2.patch,
> 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)
