To my mind the only types (or fields) that should get built-in are the ones that would break solr if they were changed. Anything else should show up in the config file. Your _nest_path_ probably falls into the "it would break solr if it changed" category.
I notice in your initial post you say "So if you were to read the schema then you'd see it." if that implies that there would be a way to fetch the final_efective_schema.xml file from the server via the admin ui that might make me feel better about this. Such a file should essentially be the schema.xml (or managed_schema.xml) with a "implicit generated types - do not edit" section. Comments etc should be preserved from the original, and possibly a provenance comment (which fields rely on the implicit addition so it's easy to spot an accidental usage of the implicit type) with each implicitly added type. Simplicity of code and code maintenance is of course excellent. Simplicity for the person trying to troubleshoot a system they've just been hired to fix/improve is also excellent. I'd prefer to SEE what's going on than have to remember what's going on modulo some version matrix in my head. Hard enough remembering which admin commands are available on version X... On Fri, Jan 4, 2019 at 10:52 PM David Smiley <david.w.smi...@gmail.com> wrote: > On Fri, Jan 4, 2019 at 12:51 PM Shawn Heisey <apa...@elyograg.org> wrote: > >> Looking at what came before, my preference would have been implicitly >> defined default types -- things like int, string, etc, defined in code. >> The only problem with that comes at Solr upgrade time ... what if we >> decide for a later version (even if it's limited to a major release) >> that IntPointField shouldn't be the implicit class for "int"? Someone >> who upgrades an index using that implicit type to the new version will >> find that Solr will no longer work. Which makes the idea unworkable. >> > > I addressed this earlier -- search for "luceneMatchVersion" which is key. > > RE a file based system schema (what Alexandre suggested)... that sounds > workable but a more complex idea that would take more code & documentation > -- at least relative to the very simple idea of some built-ins in the code > (my proposal). See SOLR-12768.patch > <https://issues.apache.org/jira/secure/attachment/12953284/SOLR-12768.patch> > changes to IndexSchema. > -- > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com > -- http://www.the111shift.com
