hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiraposter@reviews.apache.org (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4605) Constraints
Date Thu, 17 Nov 2011 07:54:53 GMT

    [ https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151892#comment-13151892

jiraposter@reviews.apache.org commented on HBASE-4605:

This is an automatically generated e-mail. To reply, visit:

(Updated 2011-11-17 07:53:56.106789)

Review request for hbase.


Based on Ted's suggestion of using the inherent serialization in HTD, I attempted to switch
over. However, this was met with some problems of going to/from String/byte[] in the value.
This lead to the large number of changes in the current patch.

Essentially, I abstracted out the serialization/deserialization mechanism from the methods
into two sets of guava functions (one set for keys, one for values) so we can encapsulate
the serialization and in the future make it easier to change. With this encapsulation, I also
updated the way CPs are stored to also use the built-in HTD serialization/deserialization

This patch also attempts to fix the remaining issues recently brought up in 4605, namely:
- Using a ConstraintException to specify an allowed constraint
- Just unloading the entire ConstraintProcessor on a runtimeexception
- dropping all the attempts at making Constraints (the class) thread safe

I'm working on the shell stuff (been busy), but figured I would throw this up in the meantime
so we can get the java stuff solid.


Most of the implementation for adding constraints as a coprocessor. 

Looking for general comments on style/structure, though nitpicks are ok too. 

Currently missing implementation for disableConstraints() since that will require adding removeCoprocessor()
to HTD (also comments on if this is worth it would be good). 

This addresses bug HBASE-4605.

Diffs (updated)

  src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java 99875b8 
  src/main/java/org/apache/hadoop/hbase/constraint/BaseConstraint.java PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/constraint/Constraint.java PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/constraint/ConstraintException.java PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/constraint/ConstraintProcessor.java PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/constraint/Constraints.java PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/constraint/IntegerConstraint.java PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/constraint/package-info.java PRE-CREATION 
  src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java ef47d0d 
  src/test/java/org/apache/hadoop/hbase/constraint/IntegrationTestConstraint.java PRE-CREATION

Diff: https://reviews.apache.org/r/2579/diff


Adding IntegrationTestConstraint and unit tests for Constraints and IntegerConstraint. All
of those pass.



> 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


View raw message