[
https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169548#comment-17169548
]
Erick Erickson commented on SOLR-14701:
---------------------------------------
This was one of those "Elasticsearch is much easier to get started with because
defining the schema isn't a barrier to entry" kinds of things. I've never
particularly liked it for the reasons you outline.
The point is though that you can index docs right OOB without having to define
a schema. True, the search is crappy. True, eventually you have to get into
tweaking the schema, true, true, true but it's easy to start.
So I wonder how much of that ease of startup we could get if we just changed
the default managed-schema to include:
{code}
<dynamicField name="*" type="text_general" indexed="true" stored="true"
multiValued="true"/>
{code}
or something like that rather than the whole schemaless approach. And if this
works, how I wish I'd been smart enough to suggest it when schemaless was
initially proposed, it would have saved a world of work.
> 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
