[
https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129155#comment-13129155
]
nkeywal commented on HBASE-4605:
--------------------------------
It would be a very useful features.
For what it worth, I am quite fine with method 2.
Some points I found useful in the SQL engines:
- capacity to disable the constraints for a connection (basically because
yoy're doing a big set of operation and you want the best possible performances
- capacity to disable globally (upgrade)
I also wonder how we should manage the evolution of the constraint. On an SQL
db, there is only one possible set; considering the amount of data, the
traditional upgrade if the traditional sql db could not be possible here; so
managing evolution of constraint would make sense.
A comment as well: in a SQL system, the constraints are linked to the
transaction: it's checked once the transaction is committed. This is important
for cross table constraint checks, as there is no transaction between tables in
HBase. I would tend to believe that's mainly a question of documentation
(insert in the right order), but it's something to remember anyway (especially
as you want to duplicate the relationships with HBase more than with a sql
db)...
I don't know the status of HCatalog, but I think the HCatalog schema will be
transformable as HBase constraints, adding value to the two of them...
> 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
