Jesse: This is a nice initiative. Looks like the Constraint you define below is per table. Meaning it is not cross-table referential integrity.
Cheers On Mon, Oct 17, 2011 at 10:45 AM, Jesse Yates <[email protected]>wrote: > 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 > 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. > > 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. > > Thanks, > Jesse Yates >
