[
https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172996#comment-13172996
]
[email protected] commented on HBASE-4605:
------------------------------------------------------
bq. On 2011-12-20 00:20:28, Ted Yu wrote:
bq. > src/main/java/org/apache/hadoop/hbase/constraint/Constraints.java, line
278
bq. > <https://reviews.apache.org/r/2579/diff/8/?file=64473#file64473line278>
bq. >
bq. > I wish we had brought up this argument to Gary earlier.
bq.
bq. Gary Helmling wrote:
bq. I don't see how stuffing binary data into the HTD values (which is
what I argued against) is any less polluting HTD? I think the options here are:
bq.
bq. 1) store in HTD, in which case I think the current string
representation is better than what we had before with the Guava dependencies
bq. 2) store configuration for Constraints to the side, in which case
ConstraintProcessor can handle mapping configuration to the Contraint instances
however it wants.
bq.
bq. Jesse Yates wrote:
bq. What do you mean by "to the side"? Ted mentions a centralized repo in
HBASE-5070. Are you thinking of essentially a system-level table for just this
stuff - kind of an aux-meta table that can be used to store just arbitrary
data?
bq.
bq. On one hand cool, on the other, but big are the confs really going to
be in the HTD? Probably not more than a couple lines, and you may or may not
want to see it, but at the very least you will always get it, as opposed to
worrying about another moving part, that may or may not be there "on the side".
bq.
bq. Michael Stack wrote:
bq. Adding conf as String to HTD is for sure convenient. Just wondering
what it'll look like when we describe a table. What happens when we want to
alter a table? Maybe this a non-issue/just aesthetics. Have you tried it?
Not yet - I was putting all the shell work off until 4879. Figured if it looked
gross/crazy, we could handle it later. It also depends on what people are
actually doing with the configuration stuff - if its not much, then this point
is really moot - we can't really tell until people try it out and complain (or
not smile).
- Jesse
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2579/#review3990
-----------------------------------------------------------
On 2011-12-13 21:38:03, Jesse Yates wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/2579/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-13 21:38:03)
bq.
bq.
bq. Review request for hbase.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. Most of the implementation for adding constraints as a coprocessor.
bq.
bq. Looking for general comments on style/structure, though nitpicks are ok
too.
bq.
bq. Currently missing implementation for disableConstraints() since that will
require adding removeCoprocessor() to HTD (also comments on if this is worth it
would be good).
bq.
bq.
bq. This addresses bug HBASE-4605.
bq. https://issues.apache.org/jira/browse/HBASE-4605
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. src/docbkx/book.xml 9617950
bq. src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java 84a0d1a
bq. src/main/java/org/apache/hadoop/hbase/constraint/BaseConstraint.java
PRE-CREATION
bq. src/main/java/org/apache/hadoop/hbase/constraint/Constraint.java
PRE-CREATION
bq.
src/main/java/org/apache/hadoop/hbase/constraint/ConstraintException.java
PRE-CREATION
bq.
src/main/java/org/apache/hadoop/hbase/constraint/ConstraintProcessor.java
PRE-CREATION
bq. src/main/java/org/apache/hadoop/hbase/constraint/Constraints.java
PRE-CREATION
bq. src/main/java/org/apache/hadoop/hbase/constraint/package-info.java
PRE-CREATION
bq. src/test/java/org/apache/hadoop/hbase/TestHTableDescriptor.java
PRE-CREATION
bq. src/test/java/org/apache/hadoop/hbase/constraint/AllFailConstraint.java
PRE-CREATION
bq. src/test/java/org/apache/hadoop/hbase/constraint/AllPassConstraint.java
PRE-CREATION
bq.
src/test/java/org/apache/hadoop/hbase/constraint/CheckConfigurationConstraint.java
PRE-CREATION
bq.
src/test/java/org/apache/hadoop/hbase/constraint/RuntimeFailConstraint.java
PRE-CREATION
bq. src/test/java/org/apache/hadoop/hbase/constraint/TestConstraint.java
PRE-CREATION
bq. src/test/java/org/apache/hadoop/hbase/constraint/TestConstraints.java
PRE-CREATION
bq. src/test/java/org/apache/hadoop/hbase/constraint/WorksConstraint.java
PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/2579/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Adding IntegrationTestConstraint and unit tests for Constraints and
IntegerConstraint. All of those pass.
bq.
bq.
bq. Thanks,
bq.
bq. Jesse
bq.
bq.
> 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: 4605-v6.txt, 4605.v7, constraint_as_cp.txt,
> java_Constraint_v2.patch, java_HBASE-4605_v1.patch, java_HBASE-4605_v2.patch,
> java_HBASE-4605_v3.patch, java_HBASE-4605_v5.patch, java_HBASE-4605_v7.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
