Compound types and internal fields

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Compound types and internal fields

Lance Norskog-2
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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Compound types and internal fields

Yonik Seeley-2-2
On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Compound types and internal fields

Lance Norskog-2
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 <[hidden email]> wrote:

> On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Lance Norskog
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Compound types and internal fields

Jan Høydahl / Cominvent
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 <[hidden email]> wrote:
>> On Sat, Aug 7, 2010 at 3:33 AM, Lance Norskog <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> Lance Norskog
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Compound types and internal fields

Lance Norskog-2
Ah! Thank you.

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



--
Lance Norskog
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]