[
https://issues.apache.org/jira/browse/GEODE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16269804#comment-16269804
]
Karen Smoler Miller edited comment on GEODE-3063 at 11/29/17 12:26 AM:
-----------------------------------------------------------------------
Comments from Darrel S to further improve the prose and organization:
Change: Data aware function execution takes advantage of custom partitioning.
to: Data aware function execution also takes advantage of custom partitioning.
I did not find the diagram helpful:
This figure shows a region with customer data that is grouped into buckets by
customer.
In the intro to "standard custom partitioning" you jump right into what the
StringPrefixPartitionResolver does. It seems like instead you should refer them
to some other page that tells them how to do standard customer partitioning.
Here is the section I thought should be moved out of this intro paragraph:
bq. The partition resolver provided with Geode at
org.apache.geode.cache.util.StringPrefixPartitionResolvergroups entries into
buckets based on a string portion of the key. All keys must be strings,
specified with a syntax that includes a ’|’ character that delimits the string.
The substring that precedes the ’|’ delimiter within the key will be returned
by getRoutingObject.
I think for both "standard custom partitioning" and "fixed custom partitioning"
we should refer them to another section for the details of how to configure and
implement it. Given this division it might make sense to split up
"Custom-Partition your region data" into two pages titled "Standard Custom
Partitioning" and "Fixed Custom Partitioning". You also have a page titled
"Colocate Data from Different Partitioned Regions" which I think the intro
section on "Data Colocation Between Regions" should reference. Something like:
"For details on how to colocate data see...".
Under "Implementing Standard Partitioning" I would not refer to "locations" and
change the "within" terminology. So say "Implement the interface in one of the
following ways:"
1. Using a custom class
2. Using the key's class (no need to say more)
3. Using the cache callback's class
I would change this section:
bq. The implementation of a string-based partition resolver is in
org.apache.geode.cache.util.StringPrefixPartitionResolver. It does not require
any further implementation.
It should be changed to include the info I had you remove from the intro that
tells how the StringPrefixPartitionResolver behaves. I would change it to say
that the product provides an implementation of PartitionResolver named
StringPrefixPartitionResolver that you can use with no further implementation.
The "init" method is only called by the product when using a custom class
configured on the region using gfsh or cache.xml.
I would get rid of the "TradeKey" example class because it has problems and is
not worth correcting. On the "Note" just before this expound that when using
the EntryOperation passed to the getRoutingObject method, the only method that
it should use to determine the result is getKey. It should not use getOperation
nor getValue.
Since the StringPrefixPartitionResolver class is part of the product jar you
can delete the following line: For colocated data, add the
StringPrefixPartitionResolver implementation class to the CLASSPATH of your
Java clients. The resolver will work with Java single-hop clients.
I would double check this statement. I know they have been trying to make
everything double with gfsh and it is not clear to me the following could not
be done:
bq. You cannot specify a fixed partition resolver using gfsh.
This example is wrong. Change:
```
PartitionAttributes attrs =
new PartitionAttributesFactory()
.setPartitionResolver("StringPrefixPartitionResolver").create();
```
to:
{{PartitionAttributes attrs =
new PartitionAttributesFactory()
.setPartitionResolver(new StringPrefixPartitionResolver()).create();}}
was (Author: karensmolermiller):
Comments from Darrel S to further improve the prose and organization:
Change: Data aware function execution takes advantage of custom partitioning.
to: Data aware function execution also takes advantage of custom partitioning.
I did not find the diagram helpful:
This figure shows a region with customer data that is grouped into buckets by
customer.
In the intro to "standard custom partitioning" you jump right into what the
StringPrefixPartitionResolver does. It seems like instead you should refer them
to some other page that tells them how to do standard customer partitioning.
Here is the section I thought should be moved out of this intro paragraph:
bq. The partition resolver provided with Geode at
org.apache.geode.cache.util.StringPrefixPartitionResolvergroups entries into
buckets based on a string portion of the key. All keys must be strings,
specified with a syntax that includes a ’|’ character that delimits the string.
The substring that precedes the ’|’ delimiter within the key will be returned
by getRoutingObject.
I think for both "standard custom partitioning" and "fixed custom partitioning"
we should refer them to another section for the details of how to configure and
implement it. Given this division it might make sense to split up
"Custom-Partition your region data" into two pages titled "Standard Custom
Partitioning" and "Fixed Custom Partitioning". You also have a page titled
"Colocate Data from Different Partitioned Regions" which I think the intro
section on "Data Colocation Between Regions" should reference. Something like:
"For details on how to colocate data see...".
Under "Implementing Standard Partitioning" I would not refer to "locations" and
change the "within" terminology. So say "Implement the interface in one of the
following ways:"
1. Using a custom class
2. Using the key's class (no need to say more)
3. Using the cache callback's class
I would change this section:
bq. The implementation of a string-based partition resolver is in
org.apache.geode.cache.util.StringPrefixPartitionResolver. It does not require
any further implementation.
It should be changed to include the info I had you remove from the intro that
tells how the StringPrefixPartitionResolver behaves. I would change it to say
that the product provides an implementation of PartitionResolver named
StringPrefixPartitionResolver that you can use with no further implementation.
The "init" method is only called by the product when using a custom class
configured on the region using gfsh or cache.xml.
I would get rid of the "TradeKey" example class because it has problems and is
not worth correcting. On the "Note" just before this expound that when using
the EntryOperation passed to the getRoutingObject method, the only method that
it should use to determine the result is getKey. It should not use getOperation
nor getValue.
Since the StringPrefixPartitionResolver class is part of the product jar you
can delete the following line: For colocated data, add the
StringPrefixPartitionResolver implementation class to the CLASSPATH of your
Java clients. The resolver will work with Java single-hop clients.
I would double check this statement. I know they have been trying to make
everything double with gfsh and it is not clear to me the following could not
be done:
bq. You cannot specify a fixed partition resolver using gfsh.
This example is wrong. Change:
{{PartitionAttributes attrs =
new PartitionAttributesFactory()
.setPartitionResolver("StringPrefixPartitionResolver").create();}}
to:
{{PartitionAttributes attrs =
new PartitionAttributesFactory()
.setPartitionResolver(new StringPrefixPartitionResolver()).create();}}
> Improve docs on default string-based partition resolver
> -------------------------------------------------------
>
> Key: GEODE-3063
> URL: https://issues.apache.org/jira/browse/GEODE-3063
> Project: Geode
> Issue Type: Bug
> Components: docs
> Reporter: Karen Smoler Miller
> Assignee: Karen Smoler Miller
>
> The new default partition resolver at
> org.apache.geode.cache.util.StringPrefixPartitionResolver
> needs more detailed documentation.
> - An example of a string specifying a key in a region operation when this
> partition resolver is used.
> - What happens if the string specifying a key doesn't have a '|' delimiter.
> - An example of using this partition resolver to colocate two regions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
