Hmmm. My opinion is neutral on a <primitiveFieldTypes>. It would have more implementation & documentation complexity to it IMO than an implicit primitive type as I've been pushing. But still; it's alright.
Since I can't seem to convince anyone on the merits of implicit field types, I will back out this part of SOLR-12768. Instead I suppose I will add a new field type for that particular issue's need. ~ David On Sat, Jan 5, 2019 at 5:29 PM Jan Høydahl <[email protected]> wrote: > 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 <[email protected]>: > > 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 <[email protected] > [email protected]> 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 <[email protected]> >> wrote: >> >>> On Fri, Jan 4, 2019 at 12:51 PM Shawn Heisey <[email protected]> >>> 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 > > -- Lucene/Solr Search Committer (PMC), Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
