Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates
 74.125.82.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAB5sDNLca1CH-N+KY7j+62mmksK2mvNNgQ4OEm__H036R5oAFg@mail.gmail.com>
References: 
 <CAB5sDNLca1CH-N+KY7j+62mmksK2mvNNgQ4OEm__H036R5oAFg@mail.gmail.com>
Date: Mon, 17 Oct 2011 11:00:32 -0700
Message-ID: 
 <CALte62ymyPVQ3XxjxS7mpHE=8x8z0WXLBphAbrEQKCVu=_GVEg@mail.gmail.com>
Subject: Re: adding constraints
From: Ted Yu <yuzhihong@gmail.com>
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=0016363ba0d40f81aa04af826264

--0016363ba0d40f81aa04af826264
Content-Type: text/plain; charset=ISO-8859-1

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 <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
>

--0016363ba0d40f81aa04af826264--