Actually, just thinking about this a bit more, perhaps adding a function
call such as parseDate() might add too much overhead to the actual query,
perhaps it would be better to first convert the date to a timestamp at index
time and store it in a field type slong? This might be more efficient but
that still leaves the problem of obtaining the current timestamp to use in
the boost function.
On 06/08/07, Pieter Berkel <[EMAIL PROTECTED]> wrote:
>
> I've been using a simple variation of the boost function given in the
> examples used to boost more recent documents:
>
> recip(rord(creationDate),1,1000,1000)^1.3
>
> While it seems to work pretty well, I've realised that this may not be
> quite as effective as i had hoped given that the calculation is based on the
> ordinal of the field value rather than the value of the field itself. In
> cases where the field type is 'date' and the actual field values are not
> distributed evenly across all documents in the index, the value returned by
> rord() is not going to give a true reflection of document age. For example,
> using Hoss' new date faceting feature, I can see that the rate at which
> documents have been added to the index I'm maintaining has been slowly but
> steadily increasing over the past few months, and I fear this fact will skew
> the boost value calculated by the function listed above.
>
> There doesn't seem to be currently any way of performing date arithmetic
> or convert a date field into an integer (seconds since epoch?), ideally I'd
> like to be able to do something like:
>
> recip(intval(parseDate('NOW')-parseDate(creationDate)),1,1000,1000)^ 1.3
>
> so that the function calculates the boost based on the actual document
> age, rather than the relative age. Does anybody have any thoughts or
> comments on this approach?
>
> cheers,
> Piete
>
>
>
