Re: [DISCUSS] changes to registerInterest API

The usual caveat, if we're changing public API's we can introduce the new ones and deprecate the old ones for removal in a subsequent major release. -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the new GemFire book here.

Re: [DISCUSS] changes to registerInterest API

+1 On Tue, Feb 20, 2018 at 5:17 PM, Dan Smith wrote: > > > > unregisterInterestForKeys(Iterable keys) > > > > +1 > -- -John john.blum10101 (skype)

Re: [DISCUSS] changes to registerInterest API

> > unregisterInterestForKeys(Iterable keys) > +1

Re: [DISCUSS] changes to registerInterest API

While doing this work, it looks like we have an equivalent unregisterInterest(K key) that accepts a List of keys or a single key. To keep things consistent with registeringInterest, I propose that we deprecate the behavior for passing in a list as the key and we introduce: unregisterInterestForKe

Re: [DISCUSS] changes to registerInterest API

I think Dan’s suggestion clarifies the intent. Anthony > On Nov 30, 2017, at 3:54 PM, Dan Smith wrote: > > I think it should be registerInterestAll(Iterablekeys) to mirror > Collection.addAll. > > I could easily see a user creating their own Tuple class or using one that > happens to also imp

Re: [DISCUSS] changes to registerInterest API

I think it should be registerInterestAll(Iterablekeys) to mirror Collection.addAll. I could easily see a user creating their own Tuple class or using one that happens to also implement Iterable as their key. We're not doing a very good job of discouraging people to use iterable objects as their k

Re: [DISCUSS] changes to registerInterest API

No, no... good question. I just think it would be wiser if users created a single, CompositeKey class type, with properly implements equals and hashCode methods, as I pointed out. I don't see any advantage in using a java.util.Collection as a key over implementing a CompositeKey type. As such, a

Re: [DISCUSS] changes to registerInterest API

Yeah I am not sure if anyone does it,and I don't think it would be a good idea to use a collection as a key but just thought I'd ask the question... On Thu, Nov 30, 2017 at 2:33 PM John Blum wrote: > For instance, this came up recently... > > > https://stackoverflow.com/questions/46551278/gemfir

Re: [DISCUSS] changes to registerInterest API

For instance, this came up recently... https://stackoverflow.com/questions/46551278/gemfire-composite-key-pojo-as-gemfire-key I have seen other similar posts too! On Thu, Nov 30, 2017 at 2:30 PM, John Blum wrote: > Does anyone actually do this in practice? If so, yikes! > > Even if the List

Re: [DISCUSS] changes to registerInterest API

Does anyone actually do this in practice? If so, yikes! Even if the List is immutable, the elements may not be, so using a List as a key starts to open 1 up to a lot of problems. As others have pointed out in SO and other channels, information should not be kept in the key. It is perfect fine t

Re: [DISCUSS] changes to registerInterest API

I started work on the following plan: - deprecate current "ALL_KEYS" and List passing behavior in registerInterest () - add registerInterestForAllKeys(); - add registerInterest(T... keys) - add registerInterest(Iterablekeys) I might be missing something here but: With the addition of registerInter

Re: [DISCUSS] changes to registerInterest API

John's approach looks best for when you need to specify keys. For ALL_KEYS, what about an API that doesn't require a token or all keys: public void registerInterestForAllKeys(); On Fri, Nov 17, 2017 at 1:24 PM, Jason Huynh wrote: > Thanks John for the clarification! > > On Fri, Nov 17, 2017 at

Re: [DISCUSS] changes to registerInterest API

Thanks John for the clarification! On Fri, Nov 17, 2017 at 1:12 PM John Blum wrote: > This... > > > The Iterable version would handle any collection type by having the user > pass > in the iterator for the collection. > > Is not correct. > > The Collection interface itself "extends" the java.lan

Re: [DISCUSS] changes to registerInterest API

This... > The Iterable version would handle any collection type by having the user pass in the iterator for the collection. Is not correct. The Collection interface itself "extends" the java.lang.Iterable interface (see here... https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html

Re: [DISCUSS] changes to registerInterest API

Current idea is to: - deprecate current "ALL_KEYS" and List passing behavior in registerInterest() - add registerInterestAllKeys(); - add registerInterest(T... keys) and registerInterest(Iterablekeys) and not have one specifically for List or specific collections. The Iterable version would handle

Re: [DISCUSS] changes to registerInterest API

I am failing to see where registerInterest(List keys) is an issue for the key type in the region. If our region is Region then I would expect registerInterest(List). If the keys are unknown or a mix then you should have Region and thus registerInterest(List. Also, List does not restrict you from L

Re: [DISCUSS] changes to registerInterest API

Personally, I prefer the var args method (registerInterest(T... keys)) myself. It is way more convenient if I only have a few keys when calling this method then to have to add the keys to a List, especially for testing purposes. But, I typically like to pair that with a registerInterest(Iterable

Re: [DISCUSS] changes to registerInterest API

Hi Mike, The current support for List leads to compilation issues if the region is type constrained. However I think you are suggesting instead of a var args method, instead provide a registerInterest(List keys) method? So far what I am hearing requested is: deprecate current "ALL_KEYS" and List

Re: [DISCUSS] changes to registerInterest API

Geode Native C++ and .NET have: virtual void registerKeys(const std::vector> & keys, bool isDurable = false, bool getInitialValues = false, bool receiveValues = true) = 0; virtual void unregisterKeys(const std

Re: [DISCUSS] changes to registerInterest API

I don't really like the regex option - it implies that your keys are all strings. Will any other regular expressions work on non string objects? registerInterestAllKeys() seems like a better option. -Dan On Thu, Nov 16, 2017 at 4:34 PM, Michael Stolz wrote: > I don't like the vararg option. > I

Re: [DISCUSS] changes to registerInterest API

I don't like the vararg option. If i'm maintaining a list of keys i'm interested in, I want to be able to pass that List in. Varargs is a poor substitute. It might even cause problems of pushing in multiple different types. Keys must all be of one type for a given Region. I'm very much in favor o

Re: [DISCUSS] changes to registerInterest API

+1 Deprecating ALL_KEYS option; I believe this is added before we supported regex support. Doesn't seems like a new API is needed. The regex java doc clearly specifies the effect of ".*". +1 for deprecating list argument; and replacing with new API. -Anil. On Thu, Nov 16, 2017 at 3:36 PM, Ja

[DISCUSS] changes to registerInterest API

For GEODE-3813 : Region registerInterest API usage of type parameters is broken The current API to registerInterest allows a special string token “ALL_KEYS” to be passed in as the parameter to reg