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

stack commented on HBASE-5229:
------------------------------

Is this the second exercise where we arrive at the same conclusion, that 
ColumnRangeFilter is what we should use doing intra-row scan?  If so, should we 
do something to make ColumnRangeFilter use more palatable to use (add methods 
to Scan API that use the ColumnRangeFilter underneath).

What about the comparator, we should fix that?

Is it a problem, that there is no ordering between CFs Lars?

Anything else we need to fix after your explorations Lars?

Should we write up something in the book or elsewhere on 'transactions' in a 
single row is the way to go (as per Matt's supposition that making the single 
row case work properly should be good for a variety of modelings on hbase)?

Good stuff Lars.


                
> Explore building blocks for "multi-row" local transactions.
> -----------------------------------------------------------
>
>                 Key: HBASE-5229
>                 URL: https://issues.apache.org/jira/browse/HBASE-5229
>             Project: HBase
>          Issue Type: New Feature
>          Components: client, regionserver
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.94.0
>
>         Attachments: 5229-seekto-v2.txt, 5229-seekto.txt, 5229.txt
>
>
> HBase should provide basic building blocks for multi-row local transactions. 
> Local means that we do this by co-locating the data. Global (cross region) 
> transactions are not discussed here.
> After a bit of discussion two solutions have emerged:
> 1. Keep the row-key for determining grouping and location and allow efficient 
> intra-row scanning. A client application would then model tables as 
> HBase-rows.
> 2. Define a prefix-length in HTableDescriptor that defines a grouping of 
> rows. Regions will then never be split inside a grouping prefix.
> #1 is true to the current storage paradigm of HBase.
> #2 is true to the current client side API.
> I will explore these two with sample patches here.
> --------------------
> Was:
> As discussed (at length) on the dev mailing list with the HBASE-3584 and 
> HBASE-5203 committed, supporting atomic cross row transactions within a 
> region becomes simple.
> I am aware of the hesitation about the usefulness of this feature, but we 
> have to start somewhere.
> Let's use this jira for discussion, I'll attach a patch (with tests) 
> momentarily to make this concrete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to