You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jinmei Liao <ji...@pivotal.io> on 2018/02/07 17:49:24 UTC
[PROPOSAL]: deprecating create region using --template-region option
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
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by John Blum <jb...@pivotal.io>.
Exactly, a logging/auditing *CacheListener* would possibly be useful across
multiple Regions, for instance.
Again, I don't know that this feature is as useful in tooling when an
application largely drives that based on UCs/workflows and data access
patterns. I.e. there are many ways to skin a cat that are not necessarily
database specific, nor should they be in all cases.
On Wed, Feb 7, 2018 at 11:22 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> John, I should have been more specific in my original proposal. It should
> read as "deprecating create region using --template-region" option in gfsh.
> I am sure the concept can be useful in other creation mechanism as long as
> they have a way to ensure that those callback are available on the member
> where they are trying to create the region.
>
> On Wed, Feb 7, 2018 at 10:56 AM, John Blum <jb...@pivotal.io> wrote:
>
>> +0
>>
>> As an FYI, *Spring Data Geode/GemFire* already provides such a
>> capability [1], which makes much more sense from an application standpoint
>> than a tooling standpoint.
>>
>> Having said that, I would also add that this capability is 1 of the more
>> popular features in SDG (particularly from customers). Just because it
>> does not make sense in all cases and for all manner of configurations does
>> not mean it is not incredibly useful. Of course, SDG also supports
>> "hierarchical" configuration, or "inheritance" in the configuration with
>> the ability to compose templates as well so that things like
>> *CacheListeners/Loaders/Writers/etc* are easily localized to where they
>> are needed, or most directly apply.
>>
>> -j
>>
>>
>> [1] https://docs.spring.io/spring-data/geode/docs/current/
>> reference/html/#bootstrap:region:templates
>>
>>
>> On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe <kh...@pivotal.io> wrote:
>>
>>> +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 <nr...@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 <
>>> agingade@pivotal.io <ma...@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 <jiliao@pivotal.io
>>> <ma...@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
>>> > >
>>> >
>>>
>>>
>>
>>
>> --
>> -John
>> john.blum10101 (skype)
>>
>
>
>
> --
> Cheers
>
> Jinmei
>
--
-John
john.blum10101 (skype)
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by John Blum <jb...@pivotal.io>.
Exactly, a logging/auditing *CacheListener* would possibly be useful across
multiple Regions, for instance.
Again, I don't know that this feature is as useful in tooling when an
application largely drives that based on UCs/workflows and data access
patterns. I.e. there are many ways to skin a cat that are not necessarily
database specific, nor should they be in all cases.
On Wed, Feb 7, 2018 at 11:22 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> John, I should have been more specific in my original proposal. It should
> read as "deprecating create region using --template-region" option in gfsh.
> I am sure the concept can be useful in other creation mechanism as long as
> they have a way to ensure that those callback are available on the member
> where they are trying to create the region.
>
> On Wed, Feb 7, 2018 at 10:56 AM, John Blum <jb...@pivotal.io> wrote:
>
>> +0
>>
>> As an FYI, *Spring Data Geode/GemFire* already provides such a
>> capability [1], which makes much more sense from an application standpoint
>> than a tooling standpoint.
>>
>> Having said that, I would also add that this capability is 1 of the more
>> popular features in SDG (particularly from customers). Just because it
>> does not make sense in all cases and for all manner of configurations does
>> not mean it is not incredibly useful. Of course, SDG also supports
>> "hierarchical" configuration, or "inheritance" in the configuration with
>> the ability to compose templates as well so that things like
>> *CacheListeners/Loaders/Writers/etc* are easily localized to where they
>> are needed, or most directly apply.
>>
>> -j
>>
>>
>> [1] https://docs.spring.io/spring-data/geode/docs/current/
>> reference/html/#bootstrap:region:templates
>>
>>
>> On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe <kh...@pivotal.io> wrote:
>>
>>> +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 <nr...@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 <
>>> agingade@pivotal.io <ma...@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 <jiliao@pivotal.io
>>> <ma...@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
>>> > >
>>> >
>>>
>>>
>>
>>
>> --
>> -John
>> john.blum10101 (skype)
>>
>
>
>
> --
> Cheers
>
> Jinmei
>
--
-John
john.blum10101 (skype)
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by Jinmei Liao <ji...@pivotal.io>.
John, I should have been more specific in my original proposal. It should
read as "deprecating create region using --template-region" option in gfsh.
I am sure the concept can be useful in other creation mechanism as long as
they have a way to ensure that those callback are available on the member
where they are trying to create the region.
On Wed, Feb 7, 2018 at 10:56 AM, John Blum <jb...@pivotal.io> wrote:
> +0
>
> As an FYI, *Spring Data Geode/GemFire* already provides such a capability
> [1], which makes much more sense from an application standpoint than a
> tooling standpoint.
>
> Having said that, I would also add that this capability is 1 of the more
> popular features in SDG (particularly from customers). Just because it
> does not make sense in all cases and for all manner of configurations does
> not mean it is not incredibly useful. Of course, SDG also supports
> "hierarchical" configuration, or "inheritance" in the configuration with
> the ability to compose templates as well so that things like
> *CacheListeners/Loaders/Writers/etc* are easily localized to where they
> are needed, or most directly apply.
>
> -j
>
>
> [1] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#
> bootstrap:region:templates
>
>
> On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe <kh...@pivotal.io> wrote:
>
>> +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 <nr...@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 <agingade@pivotal.io
>> <ma...@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 <jiliao@pivotal.io <mailto:
>> jiliao@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
>> > >
>> >
>>
>>
>
>
> --
> -John
> john.blum10101 (skype)
>
--
Cheers
Jinmei
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by Jinmei Liao <ji...@pivotal.io>.
John, I should have been more specific in my original proposal. It should
read as "deprecating create region using --template-region" option in gfsh.
I am sure the concept can be useful in other creation mechanism as long as
they have a way to ensure that those callback are available on the member
where they are trying to create the region.
On Wed, Feb 7, 2018 at 10:56 AM, John Blum <jb...@pivotal.io> wrote:
> +0
>
> As an FYI, *Spring Data Geode/GemFire* already provides such a capability
> [1], which makes much more sense from an application standpoint than a
> tooling standpoint.
>
> Having said that, I would also add that this capability is 1 of the more
> popular features in SDG (particularly from customers). Just because it
> does not make sense in all cases and for all manner of configurations does
> not mean it is not incredibly useful. Of course, SDG also supports
> "hierarchical" configuration, or "inheritance" in the configuration with
> the ability to compose templates as well so that things like
> *CacheListeners/Loaders/Writers/etc* are easily localized to where they
> are needed, or most directly apply.
>
> -j
>
>
> [1] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#
> bootstrap:region:templates
>
>
> On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe <kh...@pivotal.io> wrote:
>
>> +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 <nr...@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 <agingade@pivotal.io
>> <ma...@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 <jiliao@pivotal.io <mailto:
>> jiliao@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
>> > >
>> >
>>
>>
>
>
> --
> -John
> john.blum10101 (skype)
>
--
Cheers
Jinmei
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by John Blum <jb...@pivotal.io>.
+0
As an FYI, *Spring Data Geode/GemFire* already provides such a capability
[1], which makes much more sense from an application standpoint than a
tooling standpoint.
Having said that, I would also add that this capability is 1 of the more
popular features in SDG (particularly from customers). Just because it
does not make sense in all cases and for all manner of configurations does
not mean it is not incredibly useful. Of course, SDG also supports
"hierarchical" configuration, or "inheritance" in the configuration with
the ability to compose templates as well so that things like
*CacheListeners/Loaders/Writers/etc* are easily localized to where they are
needed, or most directly apply.
-j
[1]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap:region:templates
On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe <kh...@pivotal.io> wrote:
> +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 <nr...@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 <agingade@pivotal.io
> <ma...@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 <jiliao@pivotal.io <mailto:
> jiliao@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
> > >
> >
>
>
--
-John
john.blum10101 (skype)
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by John Blum <jb...@pivotal.io>.
+0
As an FYI, *Spring Data Geode/GemFire* already provides such a capability
[1], which makes much more sense from an application standpoint than a
tooling standpoint.
Having said that, I would also add that this capability is 1 of the more
popular features in SDG (particularly from customers). Just because it
does not make sense in all cases and for all manner of configurations does
not mean it is not incredibly useful. Of course, SDG also supports
"hierarchical" configuration, or "inheritance" in the configuration with
the ability to compose templates as well so that things like
*CacheListeners/Loaders/Writers/etc* are easily localized to where they are
needed, or most directly apply.
-j
[1]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap:region:templates
On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe <kh...@pivotal.io> wrote:
> +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 <nr...@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 <agingade@pivotal.io
> <ma...@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 <jiliao@pivotal.io <mailto:
> jiliao@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
> > >
> >
>
>
--
-John
john.blum10101 (skype)
Re: [PROPOSAL]: deprecating create region using --template-region
option
Posted by Kenneth Howe <kh...@pivotal.io>.
+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 <nr...@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 <agingade@pivotal.io <ma...@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 <jiliao@pivotal.io <ma...@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
> >
>
Re: [PROPOSAL]: deprecating create region using --template-region
option
Posted by Kenneth Howe <kh...@pivotal.io>.
+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 <nr...@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 <agingade@pivotal.io <ma...@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 <jiliao@pivotal.io <ma...@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
> >
>
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by Nick Reich <nr...@pivotal.io>.
+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 <ag...@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 <ji...@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
> >
>
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by Nick Reich <nr...@pivotal.io>.
+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 <ag...@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 <ji...@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
> >
>
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by Anilkumar Gingade <ag...@pivotal.io>.
+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 <ji...@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
>
Re: [PROPOSAL]: deprecating create region using --template-region option
Posted by Anilkumar Gingade <ag...@pivotal.io>.
+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 <ji...@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
>