hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Yates (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4605) Constraints
Date Sat, 29 Oct 2011 17:33:32 GMT

    [ 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

        

Mime
View raw message