[
https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129064#comment-13129064
]
Jesse Yates commented on HBASE-4605:
------------------------------------
I've been thinking about how to go about implementing this and have two ways to
go about it.
Method 1:
My idea is to write a ConstraintProcessor that is a system level CP with system
wide support for setting constraints on a table. this requires add 'top-level'
configuration values that the user would set for constraints to run (which
would be ordered like coprocessors), but they would just implement the
'Constraint' interface. This means modifying HTD and the shell to enable all
these
This means people need to distribute the jars and set conf values similar to
what they would have to do before, but we would handle making sure the
implemented Constraints get run in the right place, and propagate the errors
(e.g. ConstraintFailedExecption) back to the users.
Pluses:
1) Allows users to get back multiple reasons why a put failed.
2) Allows a ConstraintImpl to be a subclass of any arbitrary class and not
bound to some abstract constraint.
3) People don't have to worry about it being a coprocessor - it is notionally
divorced.
Minuses:
1) Requires changing a bunch of code in HTableDescriptor and essentially
duplicating a lot the checking/setting already done for coprocessors. This can
be gotten around by generalizing the mechanism for storing classes in the HTD.
Method 2 (already implemented, patch coming):
Add superclass AbstractConstraint which only exposes a check(Put) method. It is
actually a Coprocoessor which is loaded, processes the check and then returns
the error to the client (wrapped in an IOException) on failure.
Pluses:
1) We don't have to implement any new mechanisms for specifying the constraint,
people just have to add it as a coprocessor.
Minuses:
1) It could be confusing since with this mechanism, you just want people to
think in terms of Constraints, not coprocessors
2) You are bound to extending the AbstractCoprocessor, not just implementing
the interface
3) If just one constraint fails, then the put is rejected, so you can't find
out all the reasons it would fail (useful if cleaning data).
4) It doesn't really help 'simplify' the use of HBase. In fact, it increases
the complexity.
> Add constraints as a top-level feature
> --------------------------------------
>
> 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
>
> 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
