The decision is to go with the new behavior (I believe :-)). The region does not exist in the cluster configuration to begin with since it's not created using gfsh, so we have no way of checking unless we make an extra trip to the region to find out what kind of region it is, but again different server might have different opinion about what it is.
On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <dhard...@pivotal.io> wrote: > Since we are working on enhancing Lucene support to allow adding a Lucene > index to an existing region containing data, I am very interested in the > decision here. > Like Mike, I also prefer keeping the original behavior of updating cluster > config with both the region and the index if it was not there before. > Is there something preventing you from checking cluster config for a region > of the same name but different properties and, if so, throwing an exception > (or warning) > that cluster config could not be updated due to this collision? > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <mst...@pivotal.io> wrote: > > > Ok. Yes we do have to take the leap :) > > Let's keep thinking that way. > > > > -- > > Mike Stolz > > Principal Engineer, GemFire Product Lead > > Mobile: +1-631-835-4771 > > Download the GemFire book here. > > <https://content.pivotal.io/ebooks/scaling-data-services- > > with-pivotal-gemfire> > > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <jil...@pivotal.io> wrote: > > > > > but this proposed change is one of the effort toward "deprecating > > > cache.xml". I think we've got to take the leap at one point..... > > > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <mst...@pivotal.io> > > wrote: > > > > > > > Hmmm...I think I liked the old behavior better. It was a kind of > bridge > > > to > > > > cluster config. > > > > > > > > I still think we need to be putting much more effort into deprecating > > > > cache.xml and much less effort into fixing the (possibly) hundreds of > > > bugs > > > > related to using both cache.xml and cluster configuration at the same > > > time. > > > > If we can make cluster config complete enough, and deprecate > cache.xml, > > > > people will stop using cache.xml. > > > > > > > > > > > > > > > > -- > > > > Mike Stolz > > > > Principal Engineer, GemFire Product Lead > > > > Mobile: +1-631-835-4771 > > > > Download the GemFire book here. > > > > <https://content.pivotal.io/ebooks/scaling-data-services- > > > > with-pivotal-gemfire> > > > > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <jil...@pivotal.io> > > wrote: > > > > > > > > > Scenario: > > > > > a locator with cluster configuration enabled and a server started > > with > > > a > > > > > cache.xml that has /regionA defined and connected to this locator. > So > > > the > > > > > initial state is the locator has an empty cluster configuration for > > the > > > > > cluster, but the server has a region defined in it's cache. > > > > > > > > > > Old behavior: > > > > > when user execute "create index --region=/regionA ...." command > using > > > > gfsh, > > > > > the index creation is successful on the server, and the server > > returns > > > a > > > > > xml section that contains both <region> and <index> elements, CC is > > > > updated > > > > > with this xml, so the end result is: both region and index end up > in > > > the > > > > > cluster configuration. > > > > > > > > > > Problem with old behavior: > > > > > Not sure if the region is a cluster wide configuration. What if a > > > region > > > > > with the same name, but different type exists on different servers? > > the > > > > xml > > > > > returned by different server might be different. > > > > > > > > > > New behavior: > > > > > when user execute "create index --region=/regionA ...." command > using > > > > gfsh, > > > > > the index creation is successful on the server. We failed to find > the > > > > > region in the existing cluster configuration, so cluster > > configuration > > > > will > > > > > NOT be updated. > > > > > > > > > > I would also suggest that this would not apply to index alone, any > > > > element > > > > > inside region would have the same behavior change if we approve > this. > > > > > > > > > > Thanks! > > > > > > > > > > -- > > > > > Cheers > > > > > > > > > > Jinmei > > > > > > > > > > > > > > > > > > > > > -- > > > Cheers > > > > > > Jinmei > > > > > > -- Cheers Jinmei
