Changing external methods to no longer throw UnsupportedOperationException
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?
Re: Changing external methods to no longer throw UnsupportedOperationException
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 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? >
Re: Changing external methods to no longer throw UnsupportedOperationException
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 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 > 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? >>
Re: Changing external methods to no longer throw UnsupportedOperationException
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 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 > 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 > > 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? > >> > >
Re: Changing external methods to no longer throw UnsupportedOperationException
+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 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 > 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 > > 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? > > >> > > > > >
Re: Changing external methods to no longer throw UnsupportedOperationException
+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 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 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 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?
Re: Changing external methods to no longer throw UnsupportedOperationException
+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 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 >> 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 >>> 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 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? >>
Re: Changing external methods to no longer throw UnsupportedOperationException
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 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 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 > > >> 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 > >>> 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 > > 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? > >> > > >
Could you add my username to Geode JIRA
Hello, Could you please add jackw26 to Geode JIRA so that I can be assigned to tickets. Thanks, Jack
Re: Could you add my username to Geode JIRA
Hi Jack, Done! You should have access now. Thanks, -Dan On Thu, May 23, 2019 at 1:18 PM Jack Weissburg wrote: > Hello, > > Could you please add jackw26 to Geode JIRA so that I can be assigned to > tickets. > > Thanks, > > Jack >
