I'd really like to see these implicit types. Whether they are defined in code, in a implicit-types.xml in webapp is just implementation. Also, a <primitiveFieldTypes> would just be necessary if there is ever a need to take more explicit control, but if the right defaults are established, I see only positive effects from shipping with implicit int, long, date, bool, float, double ++ Perhaps you can sum up your final suggestion and if you don't get any vetos then go ahead :)
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 7. jan. 2019 kl. 14:40 skrev David Smiley <david.w.smi...@gmail.com>: > > 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 <jan....@cominvent.com > <mailto:jan....@cominvent.com>> 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 <david.w.smi...@gmail.com > <mailto: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.com >> <mailto:gus.h...@gmail.com>gus.h...@gmail.com <mailto: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 >> <mailto:david.w.smi...@gmail.com>> wrote: >> On Fri, Jan 4, 2019 at 12:51 PM Shawn Heisey <apa...@elyograg.org >> <mailto: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 >> <http://linkedin.com/in/davidwsmiley> | Book: >> http://www.solrenterprisesearchserver.com >> <http://www.solrenterprisesearchserver.com/> >> >> -- >> http://www.the111shift.com <http://www.the111shift.com/>-- >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley >> <http://linkedin.com/in/davidwsmiley> | Book: >> http://www.solrenterprisesearchserver.com >> <http://www.solrenterprisesearchserver.com/>-- > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley > <http://linkedin.com/in/davidwsmiley> | Book: > http://www.solrenterprisesearchserver.com > <http://www.solrenterprisesearchserver.com/>
