I agree with Mike that whatever changes in behavior are made to the Java client library should also be made in the C++ and C# libraries.
Sarge > On 15 Feb, 2017, at 08:02, Michael Stolz <mst...@pivotal.io> wrote: > > I have strong fears that if we make these wholesale changes to existing > APIs we're going to end up breaking lots of existing code. > > For instance, if we make destroyRegion propagate when it never did before, > we may end up destroying a server side region in production that wasn't > expected. > > I will advocate for being more explicit about operations that are going to > be performed on the server. > > The other fear I have is that if we make all of these server side > operations available to the Java client but not to the C++ and C# clients > we will once again be making our C++ and C# users feel orphaned. > > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: +1-631-835-4771 > > On Wed, Feb 15, 2017 at 9:44 AM, Swapnil Bawaskar <sbawas...@pivotal.io> > wrote: > >> GEODE-1887 <https://issues.apache.org/jira/browse/GEODE-1887> was filed to >> make sure that the user experience while using Geode is similar to RDBMS >> and other data products out there. While reviewing the pull request >> <https://github.com/apache/geode/pull/390> I realized that we need to make >> other operations propagate to the server as well. These include: >> - invalidateRegion() >> - destroyRegion() >> - getSnapshotService() >> - getEntry() >> - keySet() >> - values() >> - isDestroyed() >> - containsValueForKey() >> - containsKey() >> - containsValue() >> - entrySet() >> >> Also, rather than have a user "create" a PROXY region, which is just a >> handle to a server side region, I would like to propose that >> clientCache.getRegion("name") actually creates and returns a PROXY region >> even if one was not created earlier/through cache.xml. So, in summary, the >> workflow on the client would be: >> >> ClientCacheFactory cacheFactory = new ClientCacheFactory(); >> cacheFactory.addPoolLocator("localhost", 10334); >> ClientCache clientCache = cacheFactory.create(); >> >> Region students = clientCache.getRegion("students"); >> students.put("student1", "foo"); >> assert students.size() == 1; >> >> If a client wants to have a near cache, they can still "create" a >> CACHING_PROXY region. >> >> For a CACHING_PROXY, I propose that we leave the default implementation >> unchanged, i.e. all operations work locally on the client (except CRUD >> operations that are always propagated to the server). In the case where the >> client wishes to perform operations on the server, I propose that we >> introduce a new method: >> >> /** >> * @return >> */ >> Region<K, V> serverView(); >> >> so that all operations on the returned view (Region) are performed on the >> server. >> >> In the longer term, we should break up Region into two interfaces, one that >> has methods that only work on the client (like registerInterest and >> serverView()) and other for the server. >> >> Thanks! >> Swapnil. >>
