On Tue, Nov 25, 2014 at 1:35 PM, Sean Busbey <bus...@cloudera.com> wrote:
> On Tue, Nov 25, 2014 at 12:30 PM, Christopher <ctubb...@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.
