[
https://issues.apache.org/jira/browse/HBASE-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168539#comment-13168539
]
Suraj Varma commented on HBASE-4999:
------------------------------------
I see this being used similar to a Filter which is specified client side and
executes on the server. Just like we have some out of the box filters (added
over time as well), I see some being provided out of the box. The ability to
add client specified custom constraints would be akin to custom server side
filters.
I think specifying this completely on the server side via configuration (e.g. a
constraint like column_name > threshold-value) may work & be sufficient for
some cases. I'm thinking of cases where the column names are dynamic (i.e. have
ids or attribute values embedded in them) and cannot be specified purely server
side via configuration. For these, we will need client specified constraints.
Similarly, if I have multiple constraints on different column qualifiers that
are a subset of all the qualifiers, the ability to specify this client side is
much more flexible.
So - again - this would work similar to how filters work, in my mind.
> Constraints - Enhance checkAndPut to do atomic arbitrary constraint checks
> --------------------------------------------------------------------------
>
> Key: HBASE-4999
> URL: https://issues.apache.org/jira/browse/HBASE-4999
> Project: HBase
> Issue Type: Improvement
> Components: client, coprocessors
> Affects Versions: 0.92.0
> Reporter: Suraj Varma
> Labels: CAS, checkAndPut, constraints
> Fix For: 0.94.0
>
>
> Related work: HBASE-4605
> It would be great if checkAndPut (CAS) can be enhanced to not just use a
> value comparison as a gating factor for the put, but rather have the
> capability of doing arbitrary constraint checks on the column value (where
> the current comparinator approach is a subset of possible constraints that
> can be checked). Commonly used constraints (like comparisons) can be provided
> out of the box and we should have the ability to accept custom constraints
> set by the client for the checkAndPut call.
> One use-case would be the ability to implement something like the below in
> HBase.
> Pseudo sql:
> update table-name
> set column-name = new-value
> where (column-value - new-value) > threshold-value
> ... where the mutation would go through only if the specified constraint in
> the where clause is true.
> Current options include using a co-processor to do
> preCheckAndPut/postCheckAndPut constraint checks - but this is not atomic.
> i.e. the row lock needs to be released by the co-processor before the real
> checkAndPut call, thus not meeting the atomic requirement.
> Everything above is still meant to be at row level (so, no cross-row
> constraint checking is implied here).
> And ideal end result would be that an HBase client would be able to specify a
> set of constraints on multiple column qualifiers as part of the checkAndPut
> call. The call goes through if all the constraints are satisfied or doesn't
> if any of the constraints fail. And the above checkAndPut should be
> atomically executed (just like current checkAndPut semantics).
--
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
