geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <ukohlme...@pivotal.io>
Subject Re: [DISCUSS] easy string based partitioning
Date Mon, 05 Jun 2017 15:21:34 GMT
Whilst I like the idea to make something (and yes, 
DelimitedStringPartitionResolver is the simplest), I feel that we might 
be able to do one better.

*/Could/* one possibly have an /*SPEL*/ 
<https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/expressions.html>-based

PartitionResolver for this? At least this way, we don't have to rely on 
delimiters or a strong knowledge of REGEX.

IMO, this would provide the greatest bang for buck implementation.

--Udo



On 6/2/17 19:15, Jacob Barrett wrote:
> If you implement as regular expression the user doesn't have to reformat
> their key to a specific format (akin to making them implement a class). I
> would concat the matching groups for generate the routing key.
>
> Consider RegEx: .*\bcorrelation=(\d+).*\bmaybe-something-else=(\w)
> With Keys:
> A: my,key;with:any-chars;unique=12345;correlation=678/and,maybe-something-else=a
> B: my,key;unique=876324;correlation=678;and,maybe-something-else=a,foo
> C: somthing;different=988975;correlation=678;then,maybe-something-else=ba
>
> Keys A and B would have routing key '678a'. Key C would have routing key
> '678b'.
>
> -Jake
>
>
>
> Consider
>
> On Fri, Jun 2, 2017 at 4:02 PM Darrel Schneider <dschneider@pivotal.io>
> wrote:
>
>> 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.
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message