This particular method, Region.getStatistics, when called on a client does not send a message to the server. So it returns a stats object describing the region on the client. So this would not change the behaviour on a client running an older version of geode.
On Thu, May 23, 2019 at 1:00 PM Owen Nichols <onich...@pivotal.io> wrote: > +1 > > I see no semantic difference between adding a new method vs implementing a > stub that previously threw UnsupportedOperationException > > > On May 23, 2019, at 12:56 PM, Udo Kohlmeyer <u...@apache.org> wrote: > > > > +1 to implementing this method. > > > > There is no plausible reason NOT to implement this. > > > > --Udo > > > > On 5/23/19 12:44, Dan Smith wrote: > >> +1 to implementing this method in a minor release. > >> > >> I'm with Jake on this one. Every bug we fix changes the behavior of the > >> product in some small way. This seems like a behavior change for the > better > >> - I can't picture a use case where someone is actually *relying* on this > >> method throwing UnsupportedOperationException. > >> > >> I suppose someone might write a test that this feature is not supported > - > >> but it seems like the only reason to do that would be to detect when > geode > >> starts supporting getStatistics, so they'd probably be happy to see > >> getStatistics start working! > >> > >> > >> -Dan > >> > >> On Thu, May 23, 2019 at 10:31 AM Anilkumar Gingade <aging...@pivotal.io > > > >> wrote: > >> > >>> I agree, this may not look like the usecase that one would be using or > >>> depending. Going with the backward compatibility requirement this will > be > >>> breaking that contract. > >>> Again, based on the scenario and usecases, there could be exceptions. > I am > >>> trying to see if the versioning support that's used to keep the > backward > >>> compatibility contract can be used here. > >>> > >>> On Thu, May 23, 2019 at 10:17 AM Jacob Barrett <jbarr...@pivotal.io> > >>> wrote: > >>> > >>>> But what application is going to legitimately call this method and > expect > >>>> that it throw an exception? What would be the function of that usage? > >>>> > >>>> If you assume that calling this method under these conditions had no > >>> value > >>>> and would therefor never have been called then one could argue that > >>>> implementing this method is adding a feature. It adds a case where one > >>>> could legitimately call this method under new conditions. > >>>> > >>>>> On May 23, 2019, at 10:06 AM, Anilkumar Gingade <aging...@pivotal.io > > > >>>> wrote: > >>>>> As this changes the behavior on the existing older application; it > >>> seems > >>>> to > >>>>> break the backward compatibility requirements. > >>>>> We use client versions to keep the contracts/behavior same for older > >>>>> client; can we do the same here. > >>>>> > >>>>> -Anil. > >>>>> > >>>>> > >>>>> On Thu, May 23, 2019 at 8:33 AM Darrel Schneider < > >>> dschnei...@pivotal.io> > >>>>> wrote: > >>>>> > >>>>>> Is it okay, in a minor release, to implement Region.getStatistics > for > >>>>>> partitioned regions? See GEODE-2685. The current behavior is for it > to > >>>>>> always throw UnsupportedOperationException. I doubt that any > >>>> application is > >>>>>> depending on that behavior but it could be. I know we have seen > >>> changes > >>>>>> like this in the past break the tests of other products that are > >>>> layered on > >>>>>> top of Geode. > >>>>>> Should this type of change be considered one that breaks backwards > >>>>>> compatibility? > >>>>>> > >>>> > >
