+1 for deprecating Looks to me that there are too many variations on what attributes to apply to the new region to ever get it right for all situations. As Anil said, copy and paste the command used to create the original region and modify attributes as necessary for the new region.
> On Feb 7, 2018, at 10:45 AM, Nick Reich <nre...@pivotal.io> wrote: > > +1 for deprecating --template-region. It feels like a convenience method that > by it very nature has an unobvious result and would require more effort to > understand so it could be used correctly by a user than the value that it > presents. > > On Wed, Feb 7, 2018 at 10:26 AM, Anilkumar Gingade <aging...@pivotal.io > <mailto:aging...@pivotal.io>> wrote: > +1 for deprecating --template-region > > User can always find the command used to create the region and re-use it > (or if its in script, cut and paste the line). > > -Anil. > > > On Wed, Feb 7, 2018 at 9:49 AM, Jinmei Liao <jil...@pivotal.io > <mailto:jil...@pivotal.io>> wrote: > > > Hi, All, > > > > currently, there are two ways to create a region, either to use a "--type" > > option indicating a region shortcut or a "--template-region" option > > specifying another regionPath where you want to copy the attribute from. > > > > First of all, we are not sure what set of attributes that make sense to > > copy to the new region. e.g listeners/loaders/writers, normally these are > > connected to a downstream database that user may/may not want the new > > region to read/write the same table. And the current implementation would > > fail to create a region from a template that has these custom callbacks > > (including listeners, loader, writer, compressor, resolvers etc). So we > > would like to understand how useful this command option is and if we can > > stop supporting it? > > > > Suggestions/feedback welcome! > > > > -- > > Cheers > > > > Jinmei > > >
