You would see these types in the HTTP schema API, and thus you would also end up seeing it on the admin schema screen (which uses that API). It would not be saved back to the XML file unless you're further manipulating your schema via the HTTP schema API (managed schema). I ought to verify all this manually. As I'm sure you already know, comments / formatting do not survive that round-trip.
I'm a convention over configuration believer, and thus I prefer CoC over explicitness/verbosity. I suppose all CoC arguments could be shot down with generic statements of perceived maintenance/understandability benefits. Shrug; yet surely there's a case for CoC in some cases? Let me ask you this: why is it okay for databases to not have definitions of what primitives types are yet in Solr you would rather it be explicit always? That analogy is the crux of it. I'm not arguing for "text_general" or other text analyzed types to be implicits; who knows where to draw the line there. I thought primitives would be a slam dunk. On Sat, Jan 5, 2019 at 3:07 PM Gus Heck <gus.h...@gmail.com> wrote: > 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 > -- Lucene/Solr Search Committer (PMC), Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
