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 from source). Any operation
performed will be applied on this local view, as the business logic is
applied to this data.
E.g. storing specific portfolios for a fund, and calculation will be made
for these portfolios.
PROXY - A handle to remote data source, with limited support/availability
on the source data. Similar to executing queries on remote table. The
limitation could be with:
Changing or altering the region - As NoSQL doesn't have strong security
features like SQL databases (for a reason, not to be as complex as
database).
Retrieving all the source data (entries, keys, values) - Most of the time
the clients are only interested in the data which are required for their
use-cases, this could be done by executing query or providing filter
support on collection apis.
-Anil.
On Wed, Feb 15, 2017 at 2:50 PM, Darrel Schneider <dschnei...@pivotal.io>
wrote:
> 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)
> > >
> > >
> >
>
