Not that hard to setup a cron and diff job and email when the diff is not-empty. A sort-of "is that what you expected" report.
But, for myself, I also prefer schema and then managed. I do not like schemaless mode, even for development. Instead, I prefer to do "dynamicField *". P.s. I am thinking of doing a video/webinar show-casing the RAD method based on the dynamicField *, as I see many people really do not get the workflow around it. If that's something people are interested in, let me know directly and/or subscribe to the newsletter at http://www.solr-start.com/ for an announcement. I'll treat the subscriptions over the next 24 hours as a vote :-) ---- Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 4 December 2015 at 15:15, Erick Erickson <erickerick...@gmail.com> wrote: > Actually, I rather agree with your colleagues, but then I'm something > of a curmudgeon. > > More accurately, unless you _strictly_ control the input documents, > you never know what you have in your index. I'd rather have docs fail > indexing than be indexed with, say, typos in the field names.... > > FWIW, > Erick > > On Fri, Dec 4, 2015 at 6:51 AM, Rick Leir <richard.l...@canadiana.ca> wrote: >> On Fri, Dec 4, 2015 at 12:59 AM, <solr-user-digest-h...@lucene.apache.org> >> wrote: >> >>> >>> >Just wondering if folks have any suggestions on using Schema.xml vs. >>> >Managed Schema going forward. >>> > >> >> >> We are using loosely typed languages (Perl and Javascript), and a loosely >> typed DB (CouchDB). This is consistent with running Solr in Schemaless >> mode, and doing more unit tests. When you post a doc into Solr containing a >> field which has not been seen before, Solr chooses the most appropriate >> Type. There is no Java exception and the field data is searchable. You can >> discover the Type by looking at the Solr console. We can probably log it >> too. >> >> The new field might be due to us intentionally adding it, though we should >> be methodical and systematic about adding new fields. >> >> Or it could be due to unexpected input to the ingest scripts, (but I >> believe these scripts should clean their inputs). >> >> Or it could be due to a bug in the ingest scripts. In the spirit of TDD, >> the ingest scripts should have tests so we can claim they are bug free. >> >> >> However, I brought up this topic with my colleagues here, and they are sure >> we should stick with Schema.xml. ".. some level of control and expectation >> of exactly what kind of data is in our search system wouldn't be helpful >> .." So be it. >> Cheers -- Rick
