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
have instead called localDestroyRegion and, as a client, a would want to be
careful not to destroy the server state region since I am not able to
recreate it. But they may have found destroyRegion left the server alone
and so used it because its method name is shorter. So I agree that it would
be safer to leave this method alone.
But for all the other methods that let you inspect the data in a Region
using a PROXY does anyone see a problem with fixing them to tell you what
is on the server? All these methods currently are noops (i.e. return 0 for
size always, return an empty set always for keys) so would anyone be happy
with the current implementation of them? Would fixing these to tell you the
actual size of the Region your PROXY delegates to break an existing
application?
If you create a PARTITIONED_PROXY on a member of a cluster then it forwards
all these operations to a member that has data. But if you create a
REPLICATE_PROXY on a member of a cluster none of these same operations are
fowarded. Same goes for PROXY on a client. I think all of these methods
should be brought in line with the PARTITIONED_PROXY behavior.
I found that "getSnapshotService" on a client PROXY does forward its
operations to the server. So its behavior does not need to change.
On Wed, Feb 15, 2017 at 12:33 PM, Swapnil Bawaskar <sbawas...@pivotal.io>
wrote:
> 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, so it is
> most likely being used when the client is shutting down, so fixing existing
> applications should be straight forward.
>
> On Wed, Feb 15, 2017 at 12:27 PM Swapnil Bawaskar <sbawas...@pivotal.io>
> wrote:
>
> > @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, the proposal for getRegion() is:
> > 1. lookup if the region exists already and return it; this applies to
> > regions that have been created through API and cache.xml. This is the
> > current behavior.
> > 2. If the region does not exist:
> > 2.a. check if it exists on the server, if so create a PROXY region under
> > the covers and return it. Do this only on the client
> > 2.b. If it does not exist on the server, throw an exception.
> >
> >
> >
> > On Wed, Feb 15, 2017 at 9:38 AM John Blum <jb...@pivotal.io> wrote:
> >
> > @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 getRegion("path") is on RegionService
> > <
> > http://data-docs-samples.cfapps.io/docs-gemfire/latest/
> javadocs/japi/com/gemstone/gemfire/cache/RegionService.
> html#getRegion(java.lang.String)
> > >
> > [1],
> > which both ClientCache and Cache implement, indirectly through
> > GemFireCache,
> > I might add. Therefore, getRegion("path") has a completely different
> > meaning server-side (or in the embedded "peer cache" UC).
> >
> > -j
> >
> > [1]
> >
> > http://data-docs-samples.cfapps.io/docs-gemfire/latest/
> javadocs/japi/com/gemstone/gemfire/cache/RegionService.
> html#getRegion(java.lang.String)
> >
> > On Wed, Feb 15, 2017 at 9:29 AM, Anthony Baker <aba...@pivotal.io>
> wrote:
> >
> > > 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 <sbawas...@pivotal.io>
> > > wrote:
> > > >
> > > > /**
> > > > * @return
> > > > */
> > > > Region<K, V> serverView();
> > > >
> > >
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
> >
>
