[
https://issues.apache.org/jira/browse/SOLR-15740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495743#comment-17495743
]
Jason Gerlowski commented on SOLR-15740:
----------------------------------------
The schema-edit API consists of a single endpoint ({{POST /schema}}) that takes
1 or more of a variety of possible commands ("add-field", "add-field-type",
etc.). It's really cool. I didn't know we had anything like this.
(Side note: I think it'd be cool if in addition to this bulk API, we had more
REST-ful APIs for individual operation (e.g. DELETE
"/schema/fieldtypes/existingFieldType"), but that's off-topic for this ticket.)
Anyway, the bulk API is great, but it does have one quirk that I wonder whether
we want to carry forward into v2. Specifically, the v1 API is very very loose
in how the command series is formatted within the JSON body. As an example,
both of the JSON snippets below are valid ways to create two fields and one
field type:
Commands of the same type grouped in arrays:
{code}
{
"add-field": [
{name: "foo", ...},
{name: "bar", ...}
],
"add-field-type": {"name": "myStrType", ...}
}
{code}
or, all commands as separate (but possibly repeating) top-level keys ...
{code}
{
"add-field": {name: "foo",...},
"add-field": {name: "bar",...},
"add-field-type": {name: "myStrType", ...}
}
{code}
I have a few concerns with these formats, the latter/second one in particular.
# Syntax aside, supporting multiple JSON schemas/formats adds complexity to our
code. The parsing code is harder to read. The tests need to cover more
permutations.
# The latter format can lead to JSON with duplicate keys. The JSON spec
doesn't absolutely preclude this, but it does make it clear that duplicate keys
should be [avoided where-ever
possible|https://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object].
# According to the Schema API docs, "[commands are executed in the order in
which they are
specified|https://solr.apache.org/guide/8_11/schema-api.html#multiple-commands-in-a-single-post]";.
But JSON objects are [unordered|https://www.json.org/json-en.html] by
definition. In fact, key ordering is often an implementation detail left to
serialization libraries - which makes our bulk API difficult to use!
This is all to say that I think we should use the experimental designation of
the v2 APIs to tweak our bulk-schema API a bit. I'll create a separate ticket
for this and pursue (or abandon) it independent of annotation-framework
conversion. Just jotting down my notes here so I don't forget.
> Rewrite v2 schema APIs using annotation framework
> -------------------------------------------------
>
> Key: SOLR-15740
> URL: https://issues.apache.org/jira/browse/SOLR-15740
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Labels: V2
>
> Solr's v2 APIs can be implemented in 1 of 2 possible ways: an apispec (i.e.
> JSON file) based approach that was originally conceived when the v2 APIs were
> created, and an approach that relies on annotated POJO objects which has come
> into favor more recently as it results in less duplication and inches our
> APIs ones step towards a more strongly-typed future.
> The consensus has emerged across several JIRAs that the annotated-POJO
> approach is the one that should be used going forward, and that existing v2
> APIs should be cut over as convenient.
> It's worth noting that this will cause the introspection output to lose the
> "description" text for these APIs and their parameters, as there's no support
> for this yet for annotation-based v2 APIs. See SOLR-15117 for more details.
> This ticket aims to tackle this conversion for Solr's schema APIs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
