[ 
https://issues.apache.org/jira/browse/PHOENIX-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275918#comment-14275918
 ] 

James Taylor commented on PHOENIX-1578:
---------------------------------------

+1 on the patch. Yes, for your use case it'd be potentially dangerous to impact 
existing tables. The use case I'm thinking about is transactions, if we 
implement them on top of Tephra. Tephra does not handle Deletes, so if we want 
to be able to "undo" partially committed data (i.e. in the event of a conflict 
at commit time), then we need to use Puts throughout. Since an empty value is 
treated the same as a Delete marker (in terms of query results), behavior 
wouldn't change (except in your use case - to maintain prior versions when 
KEEP_DELETED_CELLS is false).

I think they way you've done it in this patch is fine, though. Even for 
transactions, we can ask users to perform an explicit operation to make a table 
"transactional". 

> 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-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)

Reply via email to