[
https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169664#comment-17169664
]
Noble Paul commented on SOLR-14701:
-----------------------------------
[~erickerickson]
I like that suggestion. Other than the {{id}} field, everything can be
collected into that catch-all dynamic-field. The current schemaless is no
better than this solution.
We have built monsters into Solr code without evaluating if it is really useful
to our users. These "features" subtract value from the product with added code
complexity & documentation challenges
I'm +1 to removing schemaless mode altogether.
bq.I like to discuss things on the mailing list, but it seems efforts that are
in the mailing list mostly result in mostly talk and little action.
Excellent point. We seem to discuss too many things in mailing lists and
ultimately nothing gets done. The solution is to force the hands of devs by
creating a JIRA & a PR. This way we are forced to either let it happen or do a
{{-1}} (veto). When we give a veto , we are forced to come up with a real
technical reason for it. We need to ensure that the "armchair developers" do
not run the project & let the real doers take over.
> 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: [email protected]
For additional commands, e-mail: [email protected]
