You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Lance Norskog <go...@gmail.com> on 2010/08/07 09:33:15 UTC
Compound types and internal fields
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?
--
Lance Norskog
goksron@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Compound types and internal fields
Posted by Lance Norskog <go...@gmail.com>.
Ah! Thank you.
On Tue, Aug 10, 2010 at 7:04 AM, Jan Høydahl / Cominvent
<ja...@cominvent.com> 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 <yo...@lucidimagination.com> wrote:
>>> On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <go...@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
>
>
--
Lance Norskog
goksron@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Compound types and internal fields
Posted by Jan Høydahl / Cominvent <ja...@cominvent.com>.
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 <yo...@lucidimagination.com> wrote:
>> On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <go...@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
Re: Compound types and internal fields
Posted by Lance Norskog <go...@gmail.com>.
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 <yo...@lucidimagination.com> wrote:
> On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <go...@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
Re: Compound types and internal fields
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <go...@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