accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] ACCUMULO-3176
Date Tue, 25 Nov 2014 19:12:07 GMT
On Tue, Nov 25, 2014 at 1:35 PM, Sean Busbey <busbey@cloudera.com> wrote:

> On Tue, Nov 25, 2014 at 12:30 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > I'm going to challenge the validity of that veto, because "solving the
> > underlying issue of race conditions in property updates" is not the
> > intended goal of the patch, or any stated side-effect. It also doesn't
> > preclude the pursuit of a solution for that issue. Comments about race
> > conditions for property updates was a related topic brought up in the
> JIRA
> > comments thread, not in the patch or the issue description. Rather, this
> > patch solves a very different problem: avoiding the need to alter
> > properties post-creation. This is an API improvement and helps in some
> > cases where properties are utilized immediately after creation, or
> anywhere
> > where somebody might want to create a table in fewer API calls.
> >
> >
> If you could clarify a couple of parts of your concern:
>
> 1. Why do we need to avoid altering properties post-creation?
>
>
We don't necessarily *need* to. It's an API improvement and a convenience.
A user may simply want to. Right now, that's really the only choice, but
it's an artificial one... because the thrift RPC layer already supports
setting these properties at table creation time.


> 2. Where do we need to utilize properties immediately after creation?
>
>
Depends on what precisely we mean by "immediately", but there are lots of
things a user might want set from the moment the table is created. For
example: a per-table load balancer before any assignments are made, or a
table constraint set before any data can be written. One original
motivation for this was the idea of adding a per-table VolumeChooser, which
matters because the chosen directory is sticky.

There are workarounds (your suggestion: to set these properties on the
namespace before table creation), but that's a limited workaround, and this
API removes the restriction that the properties must be shared with other
tables in the same namespace, and allows us to do other things in the
future: such as easily create a table offline (ACCUMULO-1904) with no
significant impact to the table creation API.

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