[
https://issues.apache.org/jira/browse/SOLR-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911837#comment-13911837
]
Steve Rowe commented on SOLR-5653:
----------------------------------
Hi Tim,
I'll look at your new patch this afternoon, but first I'll comment on some of
your responses to my review:
{quote}
bq. 4. I think we should limit the permissible top-level registerable paths,
currently to /schema/ and /config/.
Done, but required the introduction of SolrConfigRestApi class and changes to
Solr's web.xml. At this point, ManagedResource implementers have to choose
which path makes the most sense for their resource, see
ManagedStopFilterFactory as an example.
We may be able to get away with 1 class that extends Restlet's Application by
implementing a custom Finder. However, I wanted to get something in place that
solidifies the paths the API will support as soon as possible. If we determine
a cleaner way to support /schema and /config, then we should be able to do that
without breaking client code.
{quote}
Cool, sounds like a good plan - I didn't realize a custom Finder would address
the multiple Applications issue - I'll have a look.
{quote}
bq. 6. It's important that configuration in schema.xml/solrconfig.xml remains
valid regardless of the operation of the RestManager interacting with managed
resources
I've added a check for having additional args to the
BaseManagedTokenFilterFactory however there's nothing in the RestManager
framework that enforces this.
The main idea behind my implementation is that the "managed" attribute is the
only one declared and then all initArgs are stored/managed in the managed data.
That said, I could see the validity of supporting invariant initArgs so this
might need some more work.
{quote}
Maybe it'll have to remain the case that each implementation ensures there are
no non-"managed" attributes. If nothing else, this choice ("managed" is the
only supported attribute) should be doc'd (if not already), so that
implementers know they need to perform this check.
{quote}
bq. 10. In ManagedWordSetResource.updateInitArgs(), if ignoreCase is changed
from true to false, the previous downcasing operation can't be undone. Not sure
the best way to handle this: maybe serialization should always capture the
unprocessed original versions?
This is a tough one. My thinking is that we shouldn't worry about this for now
since it seems like more work / trouble supporting than it may be worth and
seems like a client app issue vs. something that needs to be built-in to the
RestManager framework. That said, I'm also open to hearing about cases where we
should support this.
{quote}
If we don't support that use case, the request must fail. This limitation
should also be doc'd (if not already).
{quote}
bq. 12. In the current model, all managed resource GET calls will return dirty
managed resource data, rather than live data. I think it's important to make
the dirty data accessible, but we should consider whether live data should be
accessible in addition, maybe as a param to the GET call?
The use case I designed for was that updates would be applied using a core /
collection reload very soon after submitting changes to the API. In other
words, the time where live data and dirty data are different should very small
and not all that important. Mainly, I don't want to start going down the path
of implementing as version control system for what is supposed to be a simple
API for changing config settings and then reloading the core to apply them.
{quote}
Fair enough. This should be doc'd (if not already): this API may temporarily
lie to you.
{quote}
bq. 16. The patch ignores the (wt param) on GET methods - this should be fairly
simple to fix, by storing data structures rather than JSON strings on the
response; see e.g. CopyFieldCollectionResource.get().
Hmmm... Not sure what's up with this one as using wt=xml works for me without
changes. To be sure, I added test to verify XML as well as JSON.
{quote}
My bad - this was based on code inspection. I'll take another look.
> Create a RESTManager to provide REST API endpoints for reconfigurable plugins
> -----------------------------------------------------------------------------
>
> Key: SOLR-5653
> URL: https://issues.apache.org/jira/browse/SOLR-5653
> Project: Solr
> Issue Type: Sub-task
> Reporter: Steve Rowe
> Attachments: SOLR-5653.patch, SOLR-5653.patch
>
>
> It should be possible to reconfigure Solr plugins' resources and init params
> without directly editing the serialized schema or {{solrconfig.xml}} (see
> Hoss's arguments about this in the context of the schema, which also apply to
> {{solrconfig.xml}}, in the description of SOLR-4658)
> The RESTManager should allow plugins declared in either the schema or in
> {{solrconfig.xml}} to register one or more REST endpoints, one endpoint per
> reconfigurable resource, including init params. To allow for multiple plugin
> instances, registering plugins will need to provide a handle of some form to
> distinguish the instances.
> This RESTManager should also be able to create new instances of plugins that
> it has been configured to allow. The RESTManager will need its own
> serialized configuration to remember these plugin declarations.
> Example endpoints:
> * SynonymFilterFactory
> ** init params: {{/solr/collection1/config/syns/myinstance/options}}
> ** synonyms resource:
> {{/solr/collection1/config/syns/myinstance/synonyms-list}}
> * "/select" request handler
> ** init params: {{/solr/collection1/config/requestHandlers/select/options}}
> We should aim for full CRUD over init params and structured resources. The
> plugins will bear responsibility for handling resource modification requests,
> though we should provide utility methods to make this easy.
> However, since we won't be directly modifying the serialized schema and
> {{solrconfig.xml}}, anything configured in those two places can't be
> invalidated by configuration serialized elsewhere. As a result, it won't be
> possible to remove plugins declared in the serialized schema or
> {{solrconfig.xml}}. Similarly, any init params declared in either place
> won't be modifiable. Instead, there should be some form of init param that
> declares that the plugin is reconfigurable, maybe using something like
> "managed" - note that request handlers already provide a "handle" - the
> request handler name - and so don't need that to be separately specified:
> {code:xml}
> <requestHandler name="/select" class="solr.SearchHandler">
> <managed/>
> </requestHandler>
> {code}
> and in the serialized schema - a handle needs to be specified here:
> {code:xml}
> <fieldType name="text_general" class="solr.TextField"
> positionIncrementGap="100">
> ...
> <analyzer type="query">
> <tokenizer class="solr.StandardTokenizerFactory"/>
> <filter class="solr.SynonymFilterFactory" managed="english-synonyms"/>
> ...
> {code}
> All of the above examples use the existing plugin factory class names, but
> we'll have to create new RESTManager-aware classes to handle registration
> with RESTManager.
> Core/collection reloading should not be performed automatically when a REST
> API call is made to one of these RESTManager-mediated REST endpoints, since
> for batched config modifications, that could take way too long. But maybe
> reloading could be a query parameter to these REST API calls.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
