[
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: [email protected]
For additional commands, e-mail: [email protected]
