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 <jil...@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 <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 >>> > > >>> > >>> >>> >> >> >> -- >> -John >> john.blum10101 (skype) >> > > > > -- > Cheers > > Jinmei > -- -John john.blum10101 (skype)
