+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? > > >> > > > > >
