[ https://issues.apache.org/jira/browse/SOLR-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16871936#comment-16871936 ]
Gus Heck commented on SOLR-13375: --------------------------------- Attaching patch with WIP initial concept of the V1 api for this working to the point of creating an alias that thinks it's a DRA (but fails with a not yet implemented exception message if you try to send it data) API looks like this: {code:java} http://localhost:8983/solr/admin/collections?action=CREATEALIAS &name=dra_test &router.name=Dimensional[category,time] &router.0.field=myCategory_s &router.0.maxCardinality=20 &router.1.field=myDate_tdt &router.1.start=2019-01-01T00:00:00Z/MONTH &router.1.interval=%2B1MONTH &router.1.maxFutureMs=600000 &create-collection.collection.configName=_default &create-collection.numShards=2 {code} This is not mapped into the V2 API yet because although I want to do this: {code:java} "routerList": { "type": "array", "description": "A list of router property sets to be used with router type Dimensional[foo,bar] where foo and bar are valid router type names (i.e. time or category). The order must correspond to the type specification in [] in the Dimensional type, so Dimensional[category,time] would require the first set of router properties to be valid for a category routed alias, and the second set to be valid for a time routed alias. In these sets of properties, router.name will be ignored in favor of the type specified in the top level Dimensional[] router.name", "items": { "type": "object", "additionalProperties": true } } {code} enabling this v2 api JSON: {code:java} { "create-alias":{ "name":"dra_test2", "router": { "name": "Dimensional[category,time]", "routerList" : [{ "field":"myCategory_s", "maxCardinality":20 }, { "field":"myDate_tdt", "start":"2019-01-01T00:00:00Z", "interval":"+1MONTH", "maxFutureMs":600000 }] }, "create-collection": { "collection.configName":"_default", "numShards":2 } } } {code} this todo/assumption from SOLR-11913 is getting in the way ([~dsmiley]): {code:java} public void writeMap(EntryWriter ew) throws IOException { //TODO don't call toNamedList; more efficiently implement here //note: multiple values, if present, are a String[] under 1 key toNamedList().forEach((k, v) -> { {code} And throwing: {code:java} "error": { "metadata": [ "error-class", "org.apache.solr.common.SolrException", "root-error-class", "java.lang.ArrayStoreException" ], "msg": "java.lang.ArrayStoreException: arraycopy: element type mismatch: can not cast one of the elements of java.lang.Object[] to the type of the destination array, java.lang.String", "code": 400 } {code} The reason for this is that my configuration results in a SolrParams wrapper instance that has non-string (List) values in the map variable ( which carried along by the lambda as backing for getParams(), which returns String[] and uses List.toArray() with a String array parameter)... I may be able to work around this by not using toMap() but that's probably going to be messier > Dimensional Routed Aliases > -------------------------- > > Key: SOLR-13375 > URL: https://issues.apache.org/jira/browse/SOLR-13375 > Project: Solr > Issue Type: New Feature > Components: SolrCloud > Affects Versions: master (9.0) > Reporter: Gus Heck > Assignee: Gus Heck > Priority: Major > > Current available routed aliases are restricted to a single field. This > feature will allow Solr to provide data driven collection access, creation > and management based on multiple fields in a document. The collections will > be queried and updated in a unified manner via an alias. Current routing is > restricted to the values of a single field. The particularly useful > combination at this time will be Category X Time routing but Category X > Category may also be useful. More importantly, if additional routing schemes > are created in the future (either as contributions or as custom code by > users) combination among these should be supported. > It is expected that not all combinations will be useful, and that > determination of usefulness I expect to leave up to the user. Some Routing > schemes may need to be limited to be the leaf/last routing scheme for > technical reasons, though I'm not entirely convinced of that yet. If so, a > flag will be added to the RoutedAlias interface. > Initial desire is to support two levels, though if arbitrary levels can be > supported easily that will be done. > This could also have been called CompositeRoutedAlias, but that creates a TLA > clash with CategoryRoutedAlias. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org