phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriel Reid (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-1578) Support explicit storage of null values
Date Mon, 12 Jan 2015 15:44:34 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gabriel Reid updated PHOENIX-1578:
----------------------------------
    Attachment: PHOENIX-1578.patch

Patch which adds a {{STORE_NULLS}} table option that can be defined on a table, and results
in null values being explicitly stored. Behavior is not changed if this option is not added
to a table.

I'm not totally clear on what the best (or general) approach is to handle auto-upgrading the
SYSTEM.CATALOG table to include the STORE_NULLS field -- could you give me a pointer there
[~jamestaylor]?

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

Mime
View raw message