hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: adding constraints
Date Mon, 17 Oct 2011 18:10:52 GMT
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 <jesse.k.yates@gmail.com>wrote:

> On Mon, Oct 17, 2011 at 11:00 AM, Ted Yu <yuzhihong@gmail.com> 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 <jesse.k.yates@gmail.com
> > >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
> > >
> >
>

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