> On Mar 23, 2015, at 11:09 AM, Yonik Seeley <ysee...@gmail.com> wrote: > > On Mon, Mar 23, 2015 at 1:54 PM, Alexandre Rafalovitch > <arafa...@gmail.com> wrote: >> I looked at SOLR-7290, but I think the discussion should stay on the >> mailing list for at least one more iteration. >> >> My understanding that the reason copyField exists is so that a search >> actually worked out of the box. Without knowing the field names, one >> cannot say what to search. > > Some points: > - Schemaless is often just to make it easier to get started. > - If one assumes a lack of knowledge of field names, that's an issue > for non-schemaless too. > - Full-text search is only one use-case that people use Solr for... > there's lots of sorting/faceting/analytics use cases.
Under SOLR-6779, Erik Hatcher changed the data_driven_schema_configs's auto-guessed default field type from text_general to strings in order to support features other than full-text search: <https://svn.apache.org/viewvc/lucene/dev/trunk/solr/server/solr/configsets/data_driven_schema_configs/conf/solrconfig.xml?r1=1648456&r2=1648455&pathrev=1648456> It’s for exactly this reason (as Alex pointed out) that the catch-all field makes sense: there is no other full-text available. Yonik, can you suggest a path that supports both these possibilities? Because having zero fields with full text search in the default Solr configuration seems like a really bad idea to me. Steve
