Currently creating region with the same name on different groups are
allowed by gfsh. Checks are done further on the servers when creating the
region to see if the region attributes clashes with any existing region,
and the operation will fail if types are different. Here is an example
about this c
Won't this break any use case were two members need to create the same
region with different attributes? For example someone might have some
members that are empty accessors of a replicated region:
//Host data on members in group1
gfsh> create region --name=A --type=REPLICATE --group=group1
//Gro
Agree with Dan. This is the only way I know that you can create accessor
regions on peer members.
On Fri, Feb 2, 2018 at 11:07 AM, Dan Smith wrote:
> Won't this break any use case were two members need to create the same
> region with different attributes? For example someone might have some
> m
Accessor region is probably a special case. Then can we add this caviar
then: "user can not create a region with the same name of a different type
except it's a proxy region"?
On Fri, Feb 2, 2018 at 11:17 AM, Sai Boorlagadda
wrote:
> Agree with Dan. This is the only way I know that you can creat
I dont think allowing *_PROXY types with same names is sufficient. Users
can also create accessor regions by setting 'local-max-memory' for a
partition region (though not allowed for a replicate).
gfsh>create region --name=test --type=PARTITION --local-max-memory=0
Member | Status
---
Based on comments received, no changes for Geode 1.4.
On Wed, Jan 31, 2018 at 11:05 AM, Sai Boorlagadda wrote:
> Adding user@geode.apache.org to the email thread to see if any users has
> inputs.
> I'm fine showing only one version of Java docs, as a developer I access
> the Java docs in my IDE
I think we allowed too many ways for the user to do the same thing again.
if we put in this restriction, this command would fail and user has to use
PARTITION_PROXY type to create an accessor region, which is not a bad thing
after all.
So now, the rule is:
1. when user creates a non-proxy region
+1 to the proposal with the modified rule and favoring region creation with
shortcuts.
On Fri, Feb 2, 2018 at 1:56 PM, Jinmei Liao wrote:
> I think we allowed too many ways for the user to do the same thing again.
>
> if we put in this restriction, this command would fail and user has to use
> P
