In some other thread or Jira that I cannot find now I proposed a new tag in schema to make this explicit. So instead of 50 tags defining all primitive types and dynamicFields, we could have one tag:
<primitiveFiledTypes enabled=«true» dynamicMappings=«true» lazy=«true»/> This is just a draft idea. This would give a way to disable these implicit primitive types if they are made default on. A lazy mode could delay adding to scheme until first use if that saves any resources. Jan > 5. jan. 2019 kl. 21:29 skrev David Smiley <david.w.smi...@gmail.com>: > > 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.comgus.heck@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 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
