[ 
https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463425#comment-17463425
 ] 

Michael Joyner edited comment on SOLR-14701 at 12/21/21, 7:17 PM:
------------------------------------------------------------------

Excellent, and yes, as an end user, I really don't like the automatic type 
guessing, among other things, if I have mistyped a field name type mark or left 
it off by accident, I end up with bad fields in the schema with bizarre errors 
later. Like trying to feed a String to a Date setter in the POJO during 
reconstruction. I actually would prefer an error be thrown if the type mark is 
left off or invalid so that I know something is wrong and that I need to fix it.

 

I also consider the concept of "dynamic schema" as really being "dynamic 
typing" using the field type marks. That already makes it dynamic, just 
removing the "guess" a type to me makes a lot of sense. So long as you still 
have the dynamic schema entries still defined and operational, wouldn't that 
not still it make it easy entry? (Other than updating the initial tutorial a 
little).


was (Author: michael-newsrx):
Excellent, and yes, as an end user, I really don't like the automatic type 
guessing, among other things, if I have mistyped a field name type mark or left 
it off by accident, I end up with bad fields in the schema with bizarre errors 
later. Like trying to feed a String to a Date setter in the POJO during 
reconstruction. I actually would prefer an error be thrown if the type mark is 
left off or invalid so that I know something is wrong and that I need to fix it.

 

I've also consider "dynamic schema" as "dynamic typing" using the field type 
marks. That already makes it dynamic, just removing the "guess" a type to me 
makes a lot of sense. So long as you still have the dynamic schema entries 
still defined and operational, wouldn't that not still it make it easy entry? 
(Other than updating the initial tutorial a little).

> 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: Blocker
>             Fix For: main (9.0)
>
>         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.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to