lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl / Cominvent <jan....@cominvent.com>
Subject Re: Compound types and internal fields
Date Tue, 10 Aug 2010 14:04:20 GMT
Good idea about copyField. A workaround for your case could be to use an UpdateProcessor to
merge the two fields into a point type.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Training in Europe - www.solrtraining.com

On 9. aug. 2010, at 01.51, Lance Norskog wrote:

> Yup, agreed. A better way:
> 
> <copyField> is implemented in o.a.s.schema.CopyField.java as a
> one-off. Suppose <copyField> was instead a method on FieldType with
> the semantics "copy from source field to me". PointType could supply
> its own implementation.
> 
> For PointType, the implementation would be: "copy these other fields
> to me". Given
>    <copyField source="lat,lon" dest="location" />
> it would split the source string and combine the lat/lon fields into a
> PointType.
> 
> I have input data in separate lat/lon fields instead of one "lat,lon"
> format and this "impedance mismatch" is a big pain in the neck. "There
> are things you don't learn until you ship."
> 
> On Sat, Aug 7, 2010 at 5:56 AM, Yonik Seeley <yonik@lucidimagination.com> wrote:
>> On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <goksron@gmail.com> wrote:
>>> I have discovered something: if you declare a PointType the subfields
>>> exist and are addressable. If you fill in the subfields directly they
>>> appear in search results, but the parent Point does not. I did this
>>> because my input data has lat/long as separate fields. I have not
>>> tested spatial queries, filtering, etc.
>>> 
>>> Is this an accepted (or anticipated) use case? Is it worth supporting
>>> that we can fill in the parts of a compound type?
>> 
>> I would generally discourage doing this since it makes assumptions
>> about the underlying point type implementation and wouldn't work as
>> you think for geohash or spatial tile fields.
>> 
>> -Yonik
>> http://www.lucidimagination.com
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Lance Norskog
> goksron@gmail.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message