On Mon, 24 Nov 2008 20:21:17 +0200
Timo Sirainen <[EMAIL PROTECTED]> wrote:
> I think I gave enough reasons above for why I don't like this
> solution. :) I also don't like adding new shared global state databases
> just for Solr. Solr should be the one shared global state database..
fair enough - it makes more sense to me now :)
[...]
> Store the per-mailbox highest indexed UID in a new unique field created
> like "<user>/<uidvalidity>/<mailbox>". Always update it by deleting the
> old one first and then adding the new one.
you mean delete, commit, add, commit? if you replace the record, simply
submitting the new document and committing would do (of course, you must ensure
the value of the uniqueKey field matches, so SOLR replaces the old doc).
> So to find out the highest
> indexed UID for a mailbox just look it up using its unique field. For
> finding the highest indexed UID for a user's all mailboxes do a single
> query:
>
> - fl=highestuid
> - q=highestuid:[* TO *]
> - fq=user:<user>
would it be faster to say q=user:<user> AND highestuid:[ * TO *] ? ( and i
guess you'd sort DESC and return 1 record only).
> If messages are being simultaneously indexed by multiple processes the
> highest-uid value may sometimes (rarely) be set too low, but that
> doesn't matter. The next search will try to re-add some of the messages
> that were already in index, but because they'll have the same unique IDs
> than what already exists they won't get added again. The highest-uid
> gets updated and all is well.
B
_________________________
{Beto|Norberto|Numard} Meijome
Mind over matter: if you don't mind, it doesn't matter
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
