Ah! Thank you. On Tue, Aug 10, 2010 at 7:04 AM, Jan Høydahl / Cominvent <[email protected]> wrote: > 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 <[email protected]> >> wrote: >>> On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> Lance Norskog >> [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
-- Lance Norskog [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
