[
https://issues.apache.org/jira/browse/PHOENIX-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14351284#comment-14351284
]
James Taylor commented on PHOENIX-1674:
---------------------------------------
bq. Tephra already implements a custom delete marker and this should be
completely transparent to Phoenix.
I'm likely not understanding the Tephra code, but it seems like your delete
marker (an empty byte array), is going to conflict with our empty key value.
Here's an example:
{code}
CREATE TABLE T (K VARCHAR PRIMARY KEY);
UPSERT INTO T VALUES('A');
SELECT * FROM T;
{code}
In this scenario, table T would have one row with a row key of 'A' and a
KeyValue with an empty byte array. Would Tephra interpret this row as deleted?
As far as availability, we'd likely be ok waiting until an HBase 1.1 release to
release transaction support, assuming it happens within a few months. It'd be
even better to do it sooner in 0.98 - I suppose it depends on the
implementation of undelete, how far down it could be scoped (family delete
markers only for 0.98?), and if it has any b/w compat issues. Don't know if
[~apurtell] has opinions on this or if it's too early to tell.
My other thought is that it'll take time to do functional and perf testing
which could be done while waiting for the HBase release. Let's examine more
when we're together (as if the row deletion is transparent to Phoenix, I can
see the argument the other way too).
bq. It looks to me like any seek hint returned by SkipScanFilter would still be
respected regardless of ordering.
Ah, good point - didn't realize this. Probably doesn't matter then.
> Snapshot isolation transaction support through Tephra
> -----------------------------------------------------
>
> Key: PHOENIX-1674
> URL: https://issues.apache.org/jira/browse/PHOENIX-1674
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
>
> Tephra (http://tephra.io/ and https://github.com/caskdata/tephra) is one
> option for getting transaction support in Phoenix. Let's use this JIRA to
> discuss the way in which this could be integrated along with the pros and
> cons.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
