lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: SOLR-1131 - Multiple Fields per Field Type
Date Tue, 01 Dec 2009 01:22:11 GMT

: Maybe, but something needs that logic. Think relational database -- if you
: try and add a field to a schema (e.g., using some DBMS client GUI or vanilla
: command line SQL) where that name already exists, then you get a SQL
: exception. Similarly, SOLR should support such concepts. Maybe it doesn't go
: How are you screwed? If you add a field name that collides then as long as
: the FieldType checked you'd still be OK? Maybe FieldTypes that support
: multi-internal fields should have a requirement that they be configured from
: the schema.xml file themselves, so that the user configuring the entire
: schema can be made to deal with the namespacing at that level -- then if she

...but these are just two different solutions that illustrate my overall 
point: one way or another, the person editing the schema.xml file needs to 
know that these FieldTypes are going to be adding additional fields to the 
index and has to be aware of the posibility of field name collisions -- 
either because they are required to configure what those additional 
fieldnames are for these FieldTypes to prevent collisions, or because they 
have to know how to make sense of errors that might get logged if the 
system detects a collision.

So rather then try to make it entirely magical and behind the scnes, and 
still require them to know about it if a collision happens and they get an 
error, let's put it right out in front of them so they know about it and 
think it through.

if people feel that something like this...

  <fieldType name="latlon" type="LatLonFieldType" />
  <dynamicField name="location*" type=latlon" />

...where an end user can deal with these fields...


...and under the covers the field type uses...

    location__LAT + location__LON
    location_home__LAT + location_home__LON
    location_work__LAT + location_work__LON an abuse of the <dynamicField/> syntax, then we could accomplish the 
same thing with something like...

  <fieldType name="latlon" type="LatLonFieldType" />
  <field name="location" type=latlon" pattern="location__*" />
  <field name="location_home" type=latlon" pattern="location_home__*" />
  <field name="location_work" type=latlon" pattern="location_work__*" />

...but that would be more verbose, and would be somewhat confusing to try 
and use as a true dynamicField (ie: we want to support "home", "work" and 
anything else picked at run time)...

  <fieldType name="latlon" type="LatLonFieldType" />
  <field name="location" type=latlon" pattern="location*" />
  <dynamicfield name="location_*" type=latlon" pattern="??whagoeshere??" />

so why not just leverage the existing dynamicFieldsyntax/mechanism where 
schema creators already expect fields to be created at runtime, and 
already have to think about possible name collisions?


View raw message