lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: SOLR-1131 - Multiple Fields per Field Type
Date Wed, 09 Dec 2009 19:40:56 GMT
Hi All,

>> 
>> : <fieldType name="point" type="solr.PointType" dimension="2"
>> subFieldType="double"/>
>> : <field name="home" type="point" indexed="true" stored="true"/>
>>       ...
>> : And a new document of:
>> : <doc>
>> : <field name="point">39.0 -79.434</field>
>> : </doc>
>> :
>> : There are three fields created:
>> : home --  Contains the stored value
>> : home___0 - Contains 39.0 indexed as a double (as in the "double" FieldType,
>> not just a double precision)
>> : home___1 - Contains -79.434 as a double
>> 
>> Grant: All of this i understand -- the back and forth Mattmann and I have
>> been having is specificly about the idea that the "__0" and __1" should be
>> more transparent when declaring the schema.  AS it stands right now, if i
>> add this to my schema...
>> 
>> <field name="home___0" type="int" indexed="true" stored="true"/>
>> 
>> ...i can really break things.  The odds of that happening are probably
>> low, but it would still be very easy to make this type more transparent to
>> schema creators by requring that PolyFields be declared as dynamicFields.
>> so your previous example would become...
>> 
>> : <fieldType name="point" type="solr.PointType" dimension="2"
>> subFieldType="double"/>
>> : <dynamicField name="home*" type="point" indexed="true" stored="true"/>
>> 
>> ...now if i'm stupid enough to add <field name="home___0"/> it's my own
>> damn fault (just like it is right now w/o having PolyFields in Solr)
>> 
>> : > letting <dynamicField/> drive everything just seems a *lot* simpler
...
>> : > both as far as implementation, and as far as maintaining the schema.
>> :
>> : I don't agree.  It requires more configuration and more knowledge by the
>> end user and doesn't hid the details.
>> 
>> 1) My example requires 8 more characters then yours.
> 
> It's not about the characters, obviously, it's about the mindset of the person
> doing the modeling, hence...

+1.

> 
>> 2) The "end" user doesn't need to know it's a dynamic field, they still
>>    just deal with a field named "home"
>> 3) my whole point is that we shouldn't be hiding these details from the
>>    person editing the schema.xml
> 
> 
> I'm not sure I agree.  I think people would expect to use a new Field Type in
> exactly the same ways the use existing Field Types, namely anywhere they want
> (dynamic or not).  We could easily validate the schema at start up time to see
> whether they have done the scenario you describe above and throw an exception.
> 

+1 to that, as well. I had mentioned in an earlier thread about using the
APIs and code to perform such a check.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department University of
Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Mime
View raw message