Geode partitioned regions usually partition the data based on the key's
hashcode.
You can do your own partitioning by implementing the PartitionResolver
interface and configuring it on the partitioned region.
In some use cases needing to deploy your class that implements
PartitionResolver can be problematic so we would like to find a way to
offer partitioning based on a portion of the key (instead of the default
which uses the entire key) that does not require you to implement your own
PartitionResolver and does not require you to deploy your own code to do
the custom partitioning.
Another group of users that do not want to implement PartitionResolver are
non-java clients. So the solution is required to be usable by non-java
geode clients without needing to reimplement the client to support a new
feature.
Another constraint on the solution is for it to be both easy to use and
easy to implement.
The proposed solution is to provide a class named:
org.apache.geode.cache.StringPrefixPartitionResolver
This class will implement PartitionResolver and have a default constructor.
To use it you need to configure a partitioned region's PartitionResolver
using the already existing mechanism for this (api, gfsh, or xml).
The StringPrefixPartitionResolver will require all keys on its region to be
of type String.
It also requires that the string key contains at least one ':' character.
The substring of the key that precedes the first ':' is the prefix that
will be returned from "getRoutingObject".
An example of doing this in gfsh is:
create region --name=r1 --type=PARTITION
--partition-resolver=org.apache.geode.cache.StringPrefixPartitionResolver
Note that attempting to use a key that is not a String or does not contain
a ':' will throw an exception. This is to help developers realize they made
a mistake.
Note that the delimiter is always a ':'. It would be easy to made the
delimiter configurable when using apis or xml but currently gfsh does not
provide a way to pass parameters to the --partition-resolver create region
option.
The only public api change this proposal makes is the new
StringPrefixPartitionResolver class.
