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