[ https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193561#comment-17193561 ]
Alexandre Rafalovitch commented on SOLR-14701: ---------------------------------------------- Shoot. We are all missing something. The chain has to be there and always enabled. Because we are not just guessing schema (however correctly). We are also actively modifying incoming values in the ways just field mapping does not. Specifically: # We are generating IDs # We are removing blank values # We are renaming fields with spaces # We are parsing dates in custom formats So, when we disable our URPChain (as per current instructions), we also lose all of those functions and Solr suddenly starts complaining about all those things. Also, if you run a different chain (such as dedupe), it will not be doing the above things. I just checked it with `bin/post -c schemaless -type text/csv -d $'date1\n2020-08-01'` . It works out of the box and fails in two different ways once we give our switch off command. Which means, either we promote this to always on with flag on guessing URP, not whole chain. But then we will have bugs when using other chains. Or we really demote it to example schema and explain how it works so people manually include those processes in their own design. Or? Thoughts please! > 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