: 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...
location
location_home
location_work
...and under the covers the field type uses...
location__LAT + location__LON
location_home__LAT + location_home__LON
location_work__LAT + location_work__LON
...is 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?
-Hoss
