accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2079) Should not be able to create table in system namespace (accumulo)
Date Sun, 05 Jan 2014 04:16:52 GMT


Christopher Tubbs commented on ACCUMULO-2079:

[~mdrob]: This ticket was about adding restrictions to the argument checks to ensure that
users don't do bad things to the built-in namespaces. I added those restrictions here, and
*additionally* tried to make sure the error message sent back to the client is informative
(rather than simply a TApplicationException, which we wrapped as an AccumuloException with
no informative message). Perhaps I didn't go far enough, in ensuring these messages were presented
well to the client... but that wasn't the primary goal of this ticket. I created a second
ticket for that... and I fully back it.

What I'm trying to understand by your "-1", is if there's something *bad* about the fix for
*this* ticket, or if you're just annoyed it didn't go far enough (all the way back to the
client). If it is something bad with *this* ticket, I can fix that here. If it's that it didn't
go far enough... then this commit is fine as an incremental improvement, and I (we, whoever)
can still do that work under a more tightly scoped ticket (which I created as ACCUMULO-2133).

What I mean when I say I'm not forcing users to string parsing to get at the information...
I mean that this fix did not attempt to make that current requirement any better. If they
had to do that before, they still have to do that now... what I mean is that I did not add
any additional requirement to do so, but I still made the improvement to restrict table creation
in the system namespace. (Actually, I think I laid the groundwork for the improvements you're
talking about in a future commit... it just wasn't done... yet.)

The fix here did include documentation updates (minor javadoc), informative error strings,
and additional tests... it just wasn't scoped to the API issue you're talking about... it
was scoped to the restriction to create tables in namespaces. Certainly these overlap... 
but in some sense, all of our code overlaps... we have to draw the line somewhere in order
to make incremental progress. Does that mean this commit should be reverted, or that it did
not add value as an improvement, independent of that issue?

In any case, if it's a priority, I can certainly begin work on Monday on ACCUMULO-2133. However,
it was my understanding that there was some contention regarding exactly *how* the API changes
should happen, and honestly, I'd rather avoid being at the center of that controversy, and
just make progress in other areas, rather than throw myself under that particular bus. Either
way, API changes or not... this change needed to happen... because we can't have users creating
tables in the reserved namespace, or deleting built-in namespaces, etc.

> Should not be able to create table in system namespace (accumulo)
> -----------------------------------------------------------------
>                 Key: ACCUMULO-2079
>                 URL:
>             Project: Accumulo
>          Issue Type: Sub-task
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>             Fix For: 1.6.0
> The accumulo namespace should be reserved for system tables. No tables should be able
to be created or deleted in it by users.

This message was sent by Atlassian JIRA

View raw message