[
https://issues.apache.org/jira/browse/SOLR-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427381#comment-15427381
]
Alexandre Rafalovitch commented on SOLR-8029:
---------------------------------------------
I am reading the spec as a newbie, so these are comments in light of that:
h4. Solr Resources description
* core ? - we should mention/explain *core* not just mention it
* configset - Zookeeper only? What about for non SolrCloud installations
* Non-distributed collection terminology - Is it still collection or core? Or
both
h4. Conventions
* What's SMILE? Takes a while to find reference to some binary JSON, but the
fasterxml website was (is?) dead, maybe cross-reference JIRA we implemented it
* Query endpoints return a lot more formats (CSV, PHP, Python, HTML from
/browse). Are those not discussed somehow?
* HJSON or HOCON (misspelling or two different things?)
* _Endpoints that require input payloads_ - does this include "update"
endpoint? What about XML Update format? What about /extract end point, is it
update? Maybe clarify this a bit.
* What's an example of an _operation key_? Forward reference I guess, but hard
to visualize this early in the document
* _Operations are specified using snake case using either a dash or underscore_
- Who is making this choice? Are some operations defined one way and others the
other? Or the client call can use either? This is super-confusing and can cause
issues to the client applications. Why can't we just have one way on this,
since everything has to be redone anyway.
* /v2/admin was already discussed for static resources, the spec should be
updated if that's accepted as the solution
h4. API Versioning
* Still talks about /solr/v2
h4. Introspection support
* Is Schema auto-generated from something or manually written?
* If it is auto-generated, what is the self-description mechanism used for
that. Because it would be good to have pluggable components (e.g. URPs,
analysers) to self-describe themselves too, it is not clear whether that would
be the same effort umbrella or a separate one.
h4. List collections
* Does the _name_ parameter support the full Java regex or just star? If just
star, there is no point being 'flexible' about. But if it is full regex (e.g.
test\[a-z\]+\[0-9\]+) , it is worth mentioning.
* _config_ param - return all collections that use the specific ?collection?
(configset I am guessing, maybe call it configset too)
h4. Create collection
* _configTemplate_? - is that same as configset? If not, need to explain.
* With async, why are we making request to one endpoint but getting its status
from another. That could mess a lot of users/tools up. Can we not proxy it
internally or something. (documentation later for delete command seem to imply
that this is already what is planned)
* Is there no useful information to be returned when collection is created?
Like which nodes it ends up on?
h4. Collection configuration
* _sharedConfigName_ vs _configTemplate_ vs - unmentioned - _configset_ - this
really needs to be explained in the resource description section
* Again, what happens without SolrCloud here? We are still supporting it or is
the assumption we will not. If we will not, this needs to be documented as
explicit precondition before merging this into master (e.g. definitely not
version 6)
h4. Collection Alias
* Endpoint (/v2/...) is completely mismatching to the example. One of them is
very out of date
* Earlier we said that alias is opaque to the user, which I read to say that
call to list the collections would return aliases as well (good for tools).
Now, it seems that they are returned in a _collection_aliases_ end point. Is
that instead or in addition? Think about Admin UI, would we want an alias in
the dropdown of options to run a query against (I would think yes)?
* No output seems to be shown, but will there be a marker that something is an
alias? Or a list of collections that alias creates?
* It would make sense to have a filter that lists all aliases a collection a
part of (it can be present in multiple I believe)
h4. Collection API and Collection Exists
* needs to be updated to use /v2/collections/collectionName structure
h4. Collection Delete
* What happens if we provide an alias name here?
h4. Swap collections?
* Do we support swapping the collections? In non-Cloud mode, obviously. And if
we only have Cloud mode, how do we support those use-cases?
h4. Collection Administration Tasks
* Examples are all-over the place in terms of URL structure.
h4. Link Config
* That's linking to which one of the _sharedConfigName_, _configTemplate_ or
_configset_?
* Can reload fail? If so, would having and not having reload=true cause
different versions of output to be present? Are there other operations that
also need reload afterwards? This should be consistent.
h4. Share Configs
* This dual-API is super-significant for tools and Admin UI. How exactly would
they know which API to use for a specific collection? What about when the name
given is an alias? The return format of calls that will allow this decision
should be really clearly documented
* Update collection
* Very confusing section. Is this taking into account swapped default and
solr-format JSON end-points? What about Solr XML Update format? Extract?
(I stopped here for now)
> Modernize and standardize Solr APIs
> -----------------------------------
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 6.0
> Reporter: Noble Paul
> Assignee: Noble Paul
> Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch,
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with
> each other or not in sync with the widely followed conventions of HTTP
> protocol. Trying to make incremental changes to make them modern is like
> applying band-aid. So, we have done a complete rethink of what the APIs
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy
> APIs will continue to work under the {{/solr}} path as they used to and they
> will be eventually deprecated.
> There are 4 types of requests in the new API
> * {{/v2/<collection-name>/*}} : Hit a collection directly or manage
> collections/shards/replicas
> * {{/v2/<core>/*}} : Hit a core directly or manage cores
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below
> for the full specification. Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
