Long term, it seems like the solution is to have a SolrConfig API that is powerful enough to define things like "df" at runtime. Definitely worth discussing what we should do until then, though.
Or pre-define a "text" field in the schemaless schema.xml file to handle > these? > I'd lean towards not defining any "df"s in the schemaless solrconfigs over this solution. I'd imagine if we define "text" in the schemaless schema.xml, a user would do the following: - index some data - query and get no results and be confused Alternatively, if we don't define any "df"s they pattern would be: - index some data - query and get error about field not specified or df not defined from there the user would at least have a starting point and decide to specify the df in the query, specify the field, or edit the solrconfig.xml and restart the service. That seems like it would result in less unexpected behavior and fewer user questions. Note, this means we should probably get rid of the "df" for /query in the schemaless example. > > I'm not even sure we _could_ make things like the spell checker play > nice with schemaless. For the other handlers we can specify &df= on > the URL once we know there's a field available, but that's tricky for > spell checking... > > And I think browse is just totally out of the question since it's > coded up for the default schema. Pull that too? > +1 on pulling both of those. > > Thoughts? > Erick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
