Going this route we could do something like: RoutableKey<RO,K> implements PartitionResolver and pass it in as a key (this was batted around in the feature narrative).
Here RO is the routing object, K is the original key. Region.put already looks for key to implement PartitonResolver and if it does will use the routing object. This way we don't need any API changes, you don't even need to set this PartitionResolver on gfsh create region and if we do this with generics you can make whatever compound key you like. Basically we're just doing the implementation and making it generic. One caveat is that this neglects .Net clients and will use more memory overhead. On Thu, Jun 1, 2017 at 2:20 PM, Michael Stolz <mst...@pivotal.io> wrote: > I think that implementing a pre-built PartitionResolver that is bundled > with Geode would enable users to leverage that PartitionResolver without > writing any code just by mentioning its class name during region creation. > > That's a huge win. Co-location without writing code. Period. Yay! > > Adding the ability to specify the delimiter is a nice add-on to that and > could probably be done by parameterizing the PartitionResolver much like > the way Listeners can be parameterized but its not there in the tooling at > this moment. > > What's bothering me is the fact that we already have a way to specify a > PartitionResolver generically built into all our tooling, and now we are > adding another way to specify this particular PartitionResolver that could > cause confusion with the current generic way, and could even run into > conflicts that we need no handle specially. > > If we have already taken care of ensuring that the class is on the > classpath, it is probably not really much easier to say > partition-by-prefix=true > than it is to say > partition-resolver=org.apache.geode.somepackage.some.class > and if we don't add "partition-by-prefix" into the API and tooling then > there's no temptation to ever say both. > > > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: +1-631-835-4771 > > On Thu, Jun 1, 2017 at 4:54 PM, Darrel Schneider <dschnei...@pivotal.io> > wrote: > > > We already have a general purpose mechanism that, if you are willing to > > write java code, handles all the permutations you mention. That mechanism > > is the PartitionResolver interface. > > > > This new feature is intended to give users a way to control how their > keys > > are partitioned without writing any java code. I think by "unnecessary > API" > > you mean "unnecessary feature". But our current features do not give you > a > > way to control partitioning without implementing a PartitionResolver. > This > > new feature allows you to just configure your region (using gfsh, xml, or > > apis) and then format your string keys to control the partitioning. No > need > > to implement a PartitionResolver. I think that is the requirement for > this > > feature. Are you arguing that this requirement does not have enough value > > for our customers to justify adding product feature for it? Or do you > think > > this requirement should be met with a different solution? > > > > On Thu, Jun 1, 2017 at 11:59 AM, Michael Stolz <mst...@pivotal.io> > wrote: > > > > > I really think that we're going down the wrong road with this > hard-coded > > > partition-by-prefix thing. > > > > > > I expect that we will have several different flavors of pre-built > > compound > > > key classes. > > > We will probably have one that takes two Integers, quite possibly one > > with > > > an Integer and a String. > > > There could be an untold number of permutations all of which are > handled > > by > > > the current way of specifying the classname. > > > It also eliminates the possibility of having both "partitionByPrefix" > > and a > > > "PartitionResolver". > > > > > > We are introducing an unnecessary API which is introducing YET ANOTHER > > WAY > > > of doing something and causing more confusion. > > > > > > As we are encountering things like both "partitionByPrefix" and a > > > "PartitionResolver" and how to deal with it I am becoming more and more > > > convinced that this is a big mistake. > > > > > > > > > -- > > > Mike Stolz > > > Principal Engineer, GemFire Product Manager > > > Mobile: +1-631-835-4771 > > > > > > On Wed, May 31, 2017 at 8:03 PM, Fred Krone (JIRA) <j...@apache.org> > > > wrote: > > > > > > > > > > > [ https://issues.apache.org/jira/browse/GEODE-3005?page= > > > > com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > > > > > > > Fred Krone updated GEODE-3005: > > > > ------------------------------ > > > > Description: > > > > A user should be able to set partition by prefix programmatically > when > > > > creating a partitioned region. > > > > > > > > This can only be done when creating a Region type Partition > > > > > > > > Implement: > > > > PartitionByKey PartitionResolver > > > > String key parser > > > > Getters and setters PartitionAttributesFactory > > > > > > > > > > > > Done: > > > > Code is reviewed and checked in > > > > Tests are created and pass > > > > > > > > Acceptance: > > > > Partitioned region can be created using new 'partition by prefix' > > > > attributes (on/off, delimiter) > > > > Only String keys work -- all other keys throw an error > > > > A String key without a delimiter is valid -- but will not be > colocated > > > > Providing a key with the correct delimiter routes the entry to the > > > correct > > > > node > > > > If partitionByPrefix has been set AND a PartitionResolver is set an > > > > IllegalArgumentException > > > > When partition-by-prefix is 'on' AND the user also sets a specific > > > > partition resolver (an implemented class), partitioning should > default > > to > > > > the implemented class. > > > > > > > > > > > > > > > > was: > > > > A user should be able to set partition by prefix programmatically > when > > > > creating a partitioned region. > > > > > > > > This can only be done when creating a Region type Partition > > > > > > > > Implement: > > > > Cache.xml XSD adding new 'partition by prefix' attribute > > > > Implement XML parser > > > > > > > > Done: > > > > Code is reviewed and checked in > > > > Tests are created and pass > > > > > > > > Acceptance: > > > > A partitioned region can be created using with 'partition by prefix' > > via > > > > cache.xml > > > > Only String keys work -- all other keys throw an error > > > > Providing a key with the correct delimiter routes the entry to the > > > correct > > > > node > > > > Providing a key with no delimiter throws an error > > > > When partition-by-prefix is 'on' AND the user also sets a specific > > > > partition resolver (an implemented class), partitioning should > default > > to > > > > the implemented class. > > > > > > > > > > > > > > > > > A developer can create a Region with Partition by Prefix using Java > > API > > > > > ------------------------------------------------------------ > > > ----------- > > > > > > > > > > Key: GEODE-3005 > > > > > URL: https://issues.apache.org/ > > jira/browse/GEODE-3005 > > > > > Project: Geode > > > > > Issue Type: Wish > > > > > Components: regions > > > > > Reporter: Fred Krone > > > > > Assignee: Fred Krone > > > > > > > > > > A user should be able to set partition by prefix programmatically > > when > > > > creating a partitioned region. > > > > > This can only be done when creating a Region type Partition > > > > > Implement: > > > > > PartitionByKey PartitionResolver > > > > > String key parser > > > > > Getters and setters PartitionAttributesFactory > > > > > Done: > > > > > Code is reviewed and checked in > > > > > Tests are created and pass > > > > > Acceptance: > > > > > Partitioned region can be created using new 'partition by prefix' > > > > attributes (on/off, delimiter) > > > > > Only String keys work -- all other keys throw an error > > > > > A String key without a delimiter is valid -- but will not be > > colocated > > > > > Providing a key with the correct delimiter routes the entry to the > > > > correct node > > > > > If partitionByPrefix has been set AND a PartitionResolver is set an > > > > IllegalArgumentException > > > > > When partition-by-prefix is 'on' AND the user also sets a specific > > > > partition resolver (an implemented class), partitioning should > default > > to > > > > the implemented class. > > > > > > > > > > > > > > > > -- > > > > This message was sent by Atlassian JIRA > > > > (v6.3.15#6346) > > > > > > > > > >
