Hi Jay
I thought external file field could not be returned as a field but
only used in scoring.
trunk has pseudo field which can take a function value but we cant
move to trunk.

also its a more general question around schema design, what happens if
you have several fields with different update frequencies. It does not
seem external file field is the use case for this.



On 10 June 2011 20:13, Jay Luker <lb...@reallywow.com> wrote:
> Take a look at ExternalFileField [1]. It's meant for exactly what you
> want to do here.
>
> FYI, there is an issue with caching of the external values introduced
> in v1.4 but, thankfully, resolved in v3.2 [2]
>
> --jay
>
> [1] 
> http://lucene.apache.org/solr/api/org/apache/solr/schema/ExternalFileField.html
> [2] https://issues.apache.org/jira/browse/SOLR-2536
>
>
> On Fri, Jun 10, 2011 at 12:54 PM, lee carroll
> <lee.a.carr...@googlemail.com> wrote:
>> Hi,
>> We have a document type which has fields which are pretty static. Say
>> they change once every 6 month. But the same document has a field
>> which changes hourly
>> What are the best approaches to index this document ?
>>
>> Eg
>> Hotel ID (static) , Hotel Description (static and costly to get from a
>> url etc), FromPrice (changes hourly)
>>
>> Option 1
>> Index hourly as a single document and don't worry about the unneeded
>> field updates
>>
>> Option 2
>> Split into 2 document types and index independently. This would
>> require the front end application to query multiple times?
>> doc1
>> ID,Description,DocType
>> doc2
>> ID,HotelID,Price,DocType
>>
>> application performs searches based on hotel attributes
>> for each hotel match issue query to get price
>>
>>
>> Any other options ? Can you query across documents ?
>>
>> We run 1.4.1, we could maybe update to 3.2 but I don't think I could
>> swing to trunk for JOIN feature (if that indeed is JOIN's use case)
>>
>> Thanks in advance
>>
>> PS Am I just worrying about de-normalised data and should sort the
>> source data out maybe by caching and get over it ...?
>>
>> cheers Lee c
>>
>

Reply via email to