Yonik, those are all facts. Which I do not disagree with at all. But there are also consequences when you bring the rest of the facts and the assumptions and documented workflows into play. My comment was trying to address the situation on that level
I am all for improving performance. I am just saying that the copyField did not seem to be an oversight. So, if we just kill it, something else will suffer. So, killing it may need a corresponding re-balancing in ??? (documentation?). For example, I am not even sure if we can create a copyField definition via REST API yet. Without that, and without global copyField, what is our default search? And if schemaless makes it easier to get started, that must cover easy to actually search too, I would guess! I am not sure if this makes sense? Regards, Alex. ---- Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter: http://www.solr-start.com/ On 23 March 2015 at 14:09, 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. > - Bad performance by default is.... bad. People tend to do benchmarks > and make sweeping conclusions based on those. > > > -Yonik
