lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norskog, Lance" <la...@divvio.com>
Subject RE: history
Date Sat, 07 Jul 2007 21:47:55 GMT
We have another use case. We would like count the number of times a
document came up in any search, and the total number of times it was
read. If these counters are not indexed, it seems like an update would
be a simple integer poke into the index. 

Also, thanks for the spellcheck info.

-----Original Message-----
From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
Seeley
Sent: Saturday, July 07, 2007 9:21 AM
To: solr-user@lucene.apache.org
Subject: Re: history

On 7/7/07, Brian Whitman <brian.whitman@variogr.am> wrote:
> I have been trying to plan out a history function for Solr. When I 
> update a document with an existing unique key, I would like the older 
> version to stay around and get tagged with the date and some metadata 
> to indicate it's not "live." Any normal search would not touch history

> documents.

Interesting...
One might be able to accomplish this with the update processors that
Ryan & I have been batting around for the last few days, in conjunction
with updateable documents, which is on-deck.

The first idea that comes to mind is that during an update, you could
change the id of the older document to be something like id_<timestamp>,
and reindex it with the addition of a live:false field.

For normal queries, use a filter of -live:false filter.
For all old of a document, use a prefix query id:mydocid_* for all
versions of a document, use query id:mydocid*

So if you can hold off a little bit, you shouldn't need a custom query
handler.  This will be a good use case to ensure that our request
processors and updateable documents are powerful enough.

-Yonik

Mime
View raw message