hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject adding constraints
Date Mon, 17 Oct 2011 17:45:21 GMT
Hey everyone,

TL;DR Adding classic DB constraints as a system level coprocessor to help
simplify using HBase and ease adopting.

Coprocessors are a really powerful mechanism and are incredibly useful for a
variety of things. However, I feel like the mechanism for using them can be
very daunting and, for certain features, could do with some simplification.

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

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.

If people are interested, I would like to open a Jira on the feature. I've
got a basic implementation, but would like to expand it to be a more
integrated, top-level element of the code. I just don't want to waste my
time doing a full blown impl and then not have at least general concensus on
it being a good feature.

One of the complaints I commonly hear about HBase is that, to outsiders, it
is difficult to figure out and use (though once you do, its solid). This
would be a step to make it easier to use and adopt.

Jesse Yates

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message