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

Noble Paul edited comment on SOLR-14701 at 8/3/20, 10:02 AM:
-------------------------------------------------------------

The schema less mode is the default. It leaves a bad taste with users because 
once you got a field wrong,(which it often does) you have screwed it up. So, 
the promise is "schema less" but we essentially give the users a screwed up 
schema. The promise doesn't work. IMHO, If a user needs to hand polish the 
schema, we have failed the "schema-less" promise

If the feature is broken, the ideal experience would be to start Solr as 
[~erickerickson] mentioned (all fields are text). Use an explicit command to 
enable the schema-less mode. 


was (Author: noble.paul):
The schema less mode is the default. It leaves a bad taste with users because 
once you got a field wrong,(which it often does) you have screwed it up. So, 
the promise is "schema less" but we essentially give the users a screwed up 
schema. The promise doesn't work. IMHO, If a user needs to hand polish the 
schema, we have failed the "schema-less" promise

> Deprecate Schemaless Mode (Discussion)
> --------------------------------------
>
>                 Key: SOLR-14701
>                 URL: https://issues.apache.org/jira/browse/SOLR-14701
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Schema and Analysis
>            Reporter: Marcus Eagan
>            Priority: Major
>
> 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

Reply via email to