[
https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194783#comment-17194783
]
Alexandre Rafalovitch commented on SOLR-14701:
----------------------------------------------
Furthermore, if we pass an object that has 3 values of Float, Double, and
String types, this will NOT currently map to String type but will fallback to
default. And if that's default is defined as "defaultFieldType" rather than
default flag on a definition, then we will not run copyFields.
I guess that depends on understanding on whether 'String' is apex type that
everything falls back to when we can't figure out what's going on.
I learn towards that apex approach, which would mean simplifying default
markings and accepting that anything that widens to string (e.g. date if no
separate definition exists) will also get copyField definitions applied.
> 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
> Priority: Major
> Attachments: image-2020-08-04-01-35-03-075.png
>
>
> 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
