[
https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194751#comment-17194751
]
Alexandre Rafalovitch commented on SOLR-14701:
----------------------------------------------
This is confusing. The current implementation does not actually do any
widening. It will match any definition that can contains all types. But
java.lang.Number is super class so will accept all.
As a result,
* you can map Float and Double to Number (superclass) and don't need to
explicitly declare them.
* you cannot map Integer to Long, therefore you need to declare them both in
the URP definition
I don't think that's correct semantics. I think you should be able to just
declare the widest semantics you want to map to a type and the code does type
widening.
So, {{byte}} {{-> }}{{short ->}} {{int ->}} {{long ->}} {{float}} -> {{double
-> Number}}
Everything else converges on String.
> 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
