[
https://issues.apache.org/jira/browse/SOLR-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872310#comment-16872310
]
Gus Heck edited comment on SOLR-13375 at 6/25/19 12:31 PM:
-----------------------------------------------------------
Actually looking again this morning I realize that the writeMap method is a bit
of a red herring. It's really the conflict between the getParams() method api
and the objects I want to express. The real problem is that the v2 API (as I am
attempting to use it) wants to be able to handle more complex objects than
SolrParams really was intended for. SolrParams *is* documented as being string
to one or more strings, but that makes it hard to handle json that has
properties that are lists of objects (lists of strings clearly work).
Autoscaling seems to be using lists of object for set-trigger.actions but
AFAICT they don't have a v1 api and I suspect they therefore dodge this
SolrParams.toMap()/getParam() issue. One possible way around this might be to
override toMap() in the wrapper to just return the map that backs the wrapper,
but that has to still somehow do the conversions to v1 api keys before
returning the map, and it widens the actual capabilities of SolrParams beyond
it's documentation which could trip up other folks.
was (Author: gus_heck):
Actually looking again this morning I realize that the writeParams method is a
bit of a red herring. It's really the conflict between the getParams() method
api and the objects I want to express. The real problem is that the v2 API (as
I am attempting to use it) wants to be able to handle more complex objects than
SolrParams really was intended for. SolrParams *is* documented as being string
to one or more strings, but that makes it hard to handle json that has
properties that are lists of objects (lists of strings clearly work).
Autoscaling seems to be using lists of object for set-trigger.actions but
AFAICT they don't have a v1 api and I suspect they therefore dodge this
SolrParams.toMap()/getParam() issue. One possible way around this might be to
override toMap() in the wrapper to just return the map that backs the wrapper,
but that has to still somehow do the conversions to v1 api keys before
returning the map, and it widens the actual capabilities of SolrParams beyond
it's documentation which could trip up other folks.
> 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
> Attachments: SOLR-13375.patch
>
>
> 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
