[
https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202292#comment-17202292
]
Chris M. Hostetter commented on SOLR-14701:
-------------------------------------------
I'm replying here to comments made in the linked PR#1863 because this trend of
discussing the same thing in 17,00 different places makes no sense to me...
{quote}
{quote}
I recommend a new request handler such as `/update/guess-schema`
This way we do not need to add any new functionality, nor do we need to pass
any extra params
{quote}
@noblepaul I don't think your proposal is fully thought out.
1. This seems not orthogonal to being able to send CSV/JSON/XML/DIH to it, if
you are proposing for it to be another
one of pathVsLoaders
2. The whole 'I give you schema' proposal ignores the fact that DateParser or
BoolParser URP present in guess
process also needs to be present in whatever schema you send it to. That 'curl'
command is hiding the user from the
actual issues the guessing is supposed to help with.
3. Even your types "string vs text" is not something that can currently can
guess.
{quote}
Maybe i'm reading too much into nobles suggestion, but *MY* understanding of
his underlying point is that instead of how to _directly_ replace
AddSchemaFieldsURP with something that is _only_ a URP, and may require changes
in the URP API to be useful, we can/should instead consider adding a new
RequestHandler that _also_ uses ContentLoaders + URPs to parse "documents" from
users -- but instead of this RequestHandler using a chain that ends with
AddScheamFields + RunUpdates the request handler can then examine the
resulting SolrInputDocuments _as a batch_ and make interesting choices, and
return a custom response. Eliminating the need to have any converstaions about
how to modify the URP APIs to return more metadata to the original client,
etc...
This is the same general idea/approach discussed in SOLR-11741 and SOLR-6939
before that. (2 issues that frankly seem much more specifically relevant to
this particular PR then the current one)
> Deprecate Schemaless Mode (Discussion)
> --------------------------------------
>
> Key: SOLR-14701
> URL: https://issues.apache.org/jira/browse/SOLR-14701
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Reporter: Marcus Eagan
> Assignee: Alexandre Rafalovitch
> Priority: Major
> Attachments: image-2020-08-04-01-35-03-075.png
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> I know this won't be the most popular ticket out there, but I am growing more
> and more sympathetic to the idea that we should rip many of the freedoms out
> that cause users more harm than not. One of the freedoms I saw time and time
> again to cause issues was schemaless mode. It doesn't work as named or
> documented, so I think it should be deprecated.
> If you use it in production reliably and in a way that cannot be accomplished
> another way, I am happy to hear from more knowledgeable folks as to why
> deprecation is a bad idea.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
