Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 13 Dec 2011 05:47:30 +0000 (UTC)
From: "Gary Helmling (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <805299676.4515.1323755250781.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1672117683.1395.1318875790749.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-4605) Constraints
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168145#comment-13168145 ] 

Gary Helmling commented on HBASE-4605:
--------------------------------------

{quote}
Guava- I didn't know about the effort to get rid of guava client side, it can be pulled if it is really a big issue. I just read through 3264 - is it the case that only the client side dependencies are used for the MR stuff? For this it works out really nicely for doing the auto-serializing (see changes to the CP stuff). We could say that the set bytes for key is at your own risk, and make strings the default.
{quote}

{quote}
getValueAsBytes() - this was -1'ed in a previous iteration as constraints was the only use case for it - wrapping it with the explicit functions seemed a decent solution.
{quote}

{quote}
Configuration - As far as human readable, how often are people going to need to check those values? The HTD already just keeps around bytes, so people don't check those over the wire - constraints would remain in the same style.
How would you feel about making that configurable? I'm thinking setting a debug flag in Constraints/configuration for that value.
{quote}

Wouldn't all of these parts be solved by just serializing the Configuration as XML?  Then it's treated as a string and you don't need the HTD changes that introduce Guava, or getValueAsBytes(), and you get human readability as a nice side-effect.  I don't see any benefit to serializing Configuration as a Writable, given these issues.

{quote}
check(Put) - this could definitely be an extension. +1 on future considerations.
{quote}

I agree that this extending constraints to cover {{Delete}} and {{Increment}} could be handled as additional issues.  I just wanted to raise the question.  It's worth thinking about here, since this is introducing a new client-exposed API.  But there's still time to make additions if desired prior to 0.94.

{quote}
IntegerConstraint - In the end, I can let this go. You're right that having in the docs should be enough. Also, combined with the fact that we don't have any others by default (and that removing is far harder than adding) I'll drop it into just the docs
{quote}

Thanks, I think it's a valuable example.
                
> Constraints
> -----------
>
>                 Key: HBASE-4605
>                 URL: https://issues.apache.org/jira/browse/HBASE-4605
>             Project: HBase
>          Issue Type: Improvement
>          Components: client, coprocessors
>    Affects Versions: 0.94.0
>            Reporter: Jesse Yates
>            Assignee: Jesse Yates
>         Attachments: 4605.v7, constraint_as_cp.txt, java_Constraint_v2.patch, java_HBASE-4605_v1.patch, java_HBASE-4605_v2.patch, java_HBASE-4605_v3.patch
>
>
> From Jesse's comment on dev:
> {quote}
> 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.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira