Jesse: I agree with your observations. Constraint, defined for single table, would be useful.
Please file a JIRA and describe your strategy there. Thanks On Mon, Oct 17, 2011 at 11:04 AM, Jesse Yates <[email protected]>wrote: > On Mon, Oct 17, 2011 at 11:00 AM, Ted Yu <[email protected]> wrote: > > > Jesse: > > This is a nice initiative. > > Looks like the Constraint you define below is per table. Meaning it is > not > > cross-table referential integrity. > > > > Theoretically we could support doing this. And if people were really cheeky > with the current implementation, they could access other tables to enforce > it (though it would kill you on access time). Even so, doing the > cross-table > checks, is going to be rough on run time (cross-server locking is always > bad > news bears ;), so thinking this should definitely be a later consideration. > > > > 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 > > > > > >
