[
https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129094#comment-13129094
]
Gary Helmling commented on HBASE-4605:
--------------------------------------
{quote}
My idea is to write a ConstraintProcessor that is a system level CP with system
wide support for setting constraints on a table. this requires add 'top-level'
configuration values that the user would set for constraints to run (which
would be ordered like coprocessors), but they would just implement the
'Constraint' interface. This means modifying HTD and the shell to enable all
these
{quote}
I like the idea of using a system level coprocessor with a minimal extension
interface for the checks to be performed. For the actual interface, you could
even use Predicate from the google guava lib, or have Constraint just be a
named interface that extends Predicate<Put>. Not critical, but plugging in to
a standard interface instead of doing a one-off may enable future uses...
For setting the constraint implementations to be applied per table, I agree
that using table attributes is probably easiest. But I don't see why we need
to modify HTableDescriptor to enable this? We currently have HBASE-4554, which
is looking to enable setting table attributes for coprocessors from the shell.
It seems like we could make that sufficiently generic to enable both the
coprocessors case and this with just changes to the shell code?
> Add constraints as a top-level feature
> --------------------------------------
>
> Key: HBASE-4605
> URL: https://issues.apache.org/jira/browse/HBASE-4605
> Project: HBase
> Issue Type: Improvement
> Components: client, coprocessors
> Affects Versions: 0.94.0
> Reporter: Jesse Yates
> Assignee: Jesse Yates
>
> From Jesse's comment on dev:
> {quote}
> What I would like to propose is a simple interface that people can use to
> implement a 'constraint' (matching the classic database definition). This
> would help ease of adoption by helping HBase more easily check that box, help
> minimize code duplication across organizations, and lead to easier adoption.
> Essentially, people would implement a 'Constraint' interface for checking
> keys before they are put into a table. Puts that are valid get written to the
> table, but if not people can will throw an exception that gets propagated
> back to the client explaining why the put was invalid.
> Constraints would be set on a per-table basis and the user would be expected
> to ensure the jars containing the constraint are present on the machines
> serving that table.
> Yes, people could roll their own mechanism for doing this via coprocessors
> each time, but this would make it easier to do so, so you only have to
> implement a very minimal interface and not worry about the specifics.
> {quote}
--
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
