Adding the environment name to the table name is one approach. Or use a metadata table to hold the name of the Accumulo table using the environment as part of the key to find the correct table. The second approach can be quite flexible because the lookup key can incorporate any information - like the name of the developer. Thus every developer could have their own table in every environment.
On Wed, Jun 25, 2014 at 5:30 AM, Jianshi Huang <[email protected]> wrote: > Ah I see. Then I need to control versioning myself. A customized versioning > iterator aware of a/b/prod labels? > > Maybe there's a better way to do it. > > Jianshi > > > > On Wed, Jun 25, 2014 at 4:19 PM, Sean Busbey <[email protected]> wrote: >> >> On Wed, Jun 25, 2014 at 2:52 AM, Jianshi Huang <[email protected]> >> wrote: >>> >>> + another 2cents myself >>> >>> I think one innovative way to use the visibility tag is for version >>> controls in development. I can set, say, "alpha", "beta", "released" >>> visibility tags to each cell and set different users in testing and >>> production. Looks like this will simplify testing a lot. >>> >>> i.e. >>> - production user: "production" >>> - beta testing user: "beta" && "production" >>> - alpha testing user: "alpha" && "beta" && "production" >>> >>> BTW, will they be counted as same record with different version? Or >>> different records? >>> >>> Does that make sense? >>> >>> >> >> >> Within Accumulo those will be different cells. In HBase they will be >> different versions of the same cell. >> >> There are tradeoffs for both approaches. In Accumulo, for example, if you >> have >> >> row 1 | user props | bob | alpha | ts0 | foo=dee >> row 1 | user props | bob | beta | ts2 | foo=cats >> row 1 | user props | bob | production | ts1 | foo=bar >> >> then with your given user accesses, those users will see multiple cells >> and you'll need application logic to deal with it. >> >> >> -- >> Sean > > > > > -- > Jianshi Huang > > LinkedIn: jianshi > Twitter: @jshuang > Github & Blog: http://huangjs.github.com/
