lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
Subject Re: Feature: Solr implicitly defined field types?
Date Sat, 05 Jan 2019 22:28:57 GMT
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.smiley@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.heck@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.smiley@gmail.com>
wrote:
>>>> On Fri, Jan 4, 2019 at 12:51 PM Shawn Heisey <apache@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

Mime
View raw message