[
https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139380#comment-13139380
]
Jesse Yates commented on HBASE-4605:
------------------------------------
{quote}
w.r.t. performance after several rounds of enabling/disabling, the following
operations are both O(1):
1. retrieve Configuration object from HTD.values map for given Constraint
2. retrieve the boolean in this Configuration object for
"hbase.constraint.enabled"
There would be impact on performance if the number of constraints is high.
{quote}
I was thinking you meant just using a boolean to enable/disable the entire
constraint mechanism, rather than an individual constraint. It is faster to
remove the ConstraintProcessor from the CP list as you save the method calls
into to ConstraintProcessor to check the enabled/disabled boolean.
bq. Should we add method for enabling/disabling individual constraints to
Constraints.java ?
This starts to be a bit painful if we want to actually do enforcement of order
of constraint application you have to traverse the entire map to check for
values (however, if we assume that the map isn't big its not that big of a
deal). However, I think, in general, that it is a good idea.
I think we should also have a remove method as well as the disable method for
individual constraints - this is more of a usage consideration rather than a
runtime one. Say you added a constraint that was wrong - removing it rather
than disabling it is definitely necessary.
Also, we should also consider having:
{code}
public static void setConfiguration(HTableDescriptor desc, Class<? extends
Constraint> clazz, Configuration conf){}
{code}
That overrides the configuration set for a constraint.
> 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
