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]
