Re: [DISCUSS] easy string based partitioning

Actually it appears that parameterizing the delimeter would be quite problematic for client side single hop. -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Jun 7, 2017 1:56 PM, "Galen M O'Sullivan" wrote: > I don't think it would be

Re: [DISCUSS] easy string based partitioning

I don't think it would be that much harder to add an option for a user-specified delimiter than it would to hardcode ':' or '|'. I think the utility of that would be much higher, and that it would be a much better candidate for inclusion in geode-core. Otherwise, I think it should live in an

Re: [DISCUSS] easy string based partitioning

In regard to sending the configuration state to the clients for the partition resolver maybe the config should be a domain object independent of the business object rather than the serialized form of the partition resolver itself. The rational for this would be that non-Java clients could get

Re: [DISCUSS] easy string based partitioning

Thanks for all the feedback. Since this is such a simple resolver with a fixed delimiter the following changes were made to the original proposal: 1. The StringPrefixPartitionResolver will be in the "org.apache.geode.cache.util" package. This was done to keep it from being viewed as part of

Re: [DISCUSS] easy string based partitioning

I have to agree. Something this trivial an limiting is better suited for a blog post or examples somewhere and not a part of the core codebase. -Jake On Mon, Jun 5, 2017 at 1:27 PM Udo Kohlmeyer wrote: > My concern with this approach is that we provide an implementation

Re: [DISCUSS] easy string based partitioning

My concern with this approach is that we provide an implementation that might be a white elephant and only used by a 1% user base. In addition to that, it does really restrict the user on his keys. Whereas something a little more configurable, like a SPEL implementation, would provide a lot

Re: [DISCUSS] easy string based partitioning

Cool. This is what I was thinking too. Fred On Jun 5, 2017 12:50 PM, "Barry Oglesby" wrote: > Yes, that makes a lot of sense. Thanks for the clarification. > > Thanks, > Barry Oglesby > > > On Mon, Jun 5, 2017 at 12:06 PM, Darrel Schneider > wrote:

Re: [DISCUSS] easy string based partitioning

Yes, that makes a lot of sense. Thanks for the clarification. Thanks, Barry Oglesby On Mon, Jun 5, 2017 at 12:06 PM, Darrel Schneider wrote: > I pictured the top level parent region (your customer region) as not having > the StringPrefixPartitionResolver. Instead it

Re: [DISCUSS] easy string based partitioning

I pictured the top level parent region (your customer region) as not having the StringPrefixPartitionResolver. Instead it would just use string keys that have no prefix and use the default resolver. It would be each co-located child region (your order region) that would have the

Re: [DISCUSS] easy string based partitioning

The top-level region may not have / need a delimiter. If you have a customer region and a colocated orders region, the customer region key could be the customerId, and the orders region key could be the customerId:orderId. The colocation would be on the customerId. In the customer region, it

Re: [DISCUSS] easy string based partitioning

I like the idea of keeping the configuration 'conventional' and thus not requiring any server configuration. As soon as you need to define a regex on the server you might as well be writing PartitionResolver code. As an aside I also think that using regexes to parse keys would also introduce a

Re: [DISCUSS] easy string based partitioning

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*/

Re: [DISCUSS] easy string based partitioning

How it's different is they don't have to put any custom code on the server. There are environments where pushing code to the server is not allowed but they would still like to do co-located join queries. -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Jun 3,

Re: [DISCUSS] easy string based partitioning

The "simplest implementation" overlooks the rational for implementing it. The rational was to avoid customers having to implement classes to do partitioning. How is that any different than forcing them to conform their string keys to a very specific format we can parse in this solution. If there

Re: [DISCUSS] easy string based partitioning

We are looking for the simplest implementation. Not the best. Fixed delimeter, string only, SIMPLE. We as a team have a habit of always solving the bigger problem. Lets allow this one to be simple. -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Jun 2, 2017

Re: [DISCUSS] easy string based partitioning

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:

Re: [DISCUSS] easy string based partitioning

Hi Darrel- +1 I am largely still thinking on this one (also from a *Spring* perspective), but I like your initial concept/idea. Will provide more feedback in time. Cheers, John On Fri, Jun 2, 2017 at 4:40 PM, Michael Stolz wrote: > +1 This is the easiest way to make

Re: [DISCUSS] easy string based partitioning

+1 This is the easiest way to make colocation easy -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Jun 2, 2017 6:55 PM, "Darrel Schneider" wrote: > Geode partitioned regions usually partition the data based on the key's > hashcode. >

[DISCUSS] easy string based partitioning

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