I see caching-proxy and proxy as:
CACHING_PROXY - A VIEW (table view) to the data source, which
represents/stores data for a particular business requirement, this view is
created by interest registration or adding the entries through put (changes
are reflected in source region) or get (fetched fro
The following is in regard to methods on Region and how they behave on a
PROXY.
I agree with Mike that changing destroyRegion on a PROXY to now also
destroy the region on the server might cause existing users problems. It is
odd that they would have used this method from a client since they could
h
Re: breaking existing code; we could throw UnsupportedOperationException
for these two methods:
- invalidateRegion()
- destroyRegion()
I do not see anyone using/depending on invalidateRegion, since the behavior
currently is a no-op.
destroyRegion currently only gets rid of the handle to the region
@John The intention behind this proposal is to make Geode client
development easy for new users. So, looking at this as a new user, I would
say that having to "create" a PROXY region only to find out that it does
nothing on the server, is more confusing than an overloaded getRegion().
To summarize
@Eric-
Hmm...
Well, I'd argue that it is still confusing to "*overload*" the purpose of
getRegion("path") to dually "*get*" (the primary function/purpose) and also
"*create*" (secondary).
I'd also say that the getRegion("path") API call is not exclusive to a
*ClientCache*, particularly since get
Introducing an API like this gives us the opportunity to split the
client/server region API’s. I don’t think we should return Region, but
something specific to “server view”. How would those API’s operate on a
CACHING_PROXY?
Anthony
> On Feb 15, 2017, at 6:44 AM, Swapnil Bawaskar wrote:
>
John,
The proposed solution is actually try to solve the situation you mentioned
-- create a proxy Region failed silently on a client when region does not
reside on the server.
Region students = clientCache.getRegion("Students");
The getRegion will check on the server side and it should fail wit
I agree with what Mike said. Plus, I don't think this is as simple as it
appears.
For instance, if I ...
Region students = clientCache.getRegion("Students");
What happens when the "Students" Region does not exist server-side?
This would require a check to determine whether the Students Region
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 wrote:
>
> I have strong fears that if we make these wholesale changes to existing
> APIs we're going to end
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 ad
10 matches
Mail list logo
