[
https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139110#comment-13139110
]
Jesse Yates commented on HBASE-4605:
------------------------------------
bq. To preserve order of constraints, we can embed their ordinal in HTD key
prefix, such as "constraint 1 $", "constraint 2 $", etc.
Exactly what I was planning on doing and where I got the inspiration
{quote}
To enable/disable a constraint, the value (a Configuration object) for the key
can carry a special entry:
"hbase.constraint.enabled" -> true/false
{quote}
I was thinking I would just remove the constraint processor from the list of
coprocessors. This also gives you complete control over runtime slowdown - if
you want to enable constraints, you pay a price, but if not it shouldn't hurt
the system speed at all. This would be a good idiom for later, CP based
features to follow.
If we have the true/false it would require doing checking on the regionserver
to see if constraints are enabled AND that the CP is loaded to have the same
potential, which leads to a lot of code bloat.
> Constraints
> -----------
>
> 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
> Attachments: constraint_as_cp.txt, java_Constraint_v2.patch
>
>
> 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
