In fact, there are 12 queries which still check for unique_id != '' (or the
similar <> ''); 10 in db.c and 2 in dbsearch.c.
Off the top of my head, I can't think of any time during the message
delivery that the unique_id field should be empty without a corresponding
indicator in the status column... [starts grepping db.c]
Ah, got 'em:
db_imap_append_msg() first inserts without a unique_id but with a valid
status (value of 1, meaning read).
db_copymsg() does some weird stuff, first inserting with 'dummy' and then
using its own algorithm to generate the new unique_id.
Aaron
"Jesse Norell" <[EMAIL PROTECTED]> said:
>
>
> > My preference is that we do this for 2.1. We still need to do some more
> > bugixing in 2.0 (the Mozilla behaviour for instance) and some
> > optimizations (see if we have queries that can be optimized or done
> away
> > with)
>
> Along the lines of optimized queries/indexes, and while the
> delivery chain is under development, the unique_id in every index
> issue could/should be addressed. I couldn't find my past message
> in the archives on the issue offhand, but from what I remember, the
> only reason the unique_id was in every index was that in some places
> the messages.status column was used to mark a message being inserted,
> and in other places an empty unique_id was used for the same purpose.
> With a unified delivery chain, it'd be easy to make it always use
> the status flag (or whatever mechanism is currently in place) and
> drop the "AND unique_id!=''" from almost every query that involves
> messages, and then drop unique_id from every index but the one
> that's actually supposed to cover it.
>
> caveat: I've not looked at the 2.0 code, it's possbile this has
> already been done. :)
>
> Jn
>
>
>
> --
> Jesse Norell
>
> [EMAIL PROTECTED] is not my email address;
> change "administrator" to my first name.
> --
>
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--
