[
https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145266#comment-13145266
]
Jesse Yates commented on HBASE-4605:
------------------------------------
@Ted:
{quote}
I only see synchronized keyword on Constraints.add().
Have you tried using synchronization on other methods ?
{quote}
No I haven't, but this was the beginnings of making the setting synchronized.
However, after thinking about it, that doesn't really make all that much sense
for a bunch of static setting methods. I was going to push this off onto the
user.
{quote}
Also, HTableDescriptor.values is protected field. We can change its actual
implementation to ConcurrentHashMap, etc to accommodate for the concurrency you
described.
{quote}
Seems a little excessive especially since all the synchronization on HTD has
been done by users when necessary in the past. My hunch is that this is rarely
an issue.
{quote}
If we store metadata about constraints in the Configuration object as I
described @ 29/Oct/11 04:20, we utilize the available serialization mechanism.
The current approach deals with serialization itself. This is not as flexible
as the above approach.
{quote}
+1 Making the changes. My initial thought was to mimic how CPs are added to the
table, which handle writing their own bytes. But, yeah your recommendation
would be makes it much easier (and consistent).
@Gary:
{quote}
Some runtime exceptions could indicate programming errors or bugs, in which
case I think it's best to handle them the same way we handle unexpected errors
in coprocessors – by either unloading or aborting, depending on configuration.
We need to be careful for what we allow from user code running in process on
region servers.
{quote}
AND
{quote}
I disagree here. Treating all possible exceptions the same seems wrong. An
OutOfMemoryError is not equivalent to a NumberFormatException. We need some
structure in place for what types of errors are allowed/expected, instead of
swallowing everything and assuming it's just a constraint violation. I don't
think asking the Constraint implementations to think about what errors they
want to throw is much of a burden.
{quote}
+1 having the user propagate a DoNoRetryException subclass (eg.
ConstraintException) - you make a good point. Working on the best way to handle
unload/total failure.
{quote}
Sometimes people do weird things (I've seen people doing exactly what I was
testing against), so while ugly, is not unheard of. An examples module would be
great - I'll comment on 4336 about that. In the mean time, maybe just having an
examples package (main/java/…hbase.constraint.examples) that can be updated as
people find more uses for constraints? Though I'm not adverse to the book
either.
> 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: constraint_as_cp.txt, java_Constraint_v2.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
