On Mon, 25 Oct 2004 22:17:36 +0200, Paul J Stevens <[EMAIL PROTECTED]> wrote: > > Ok Jesse, thanks for the pointer. > > Looks like db_imap_append uses its own version of the insertion logic and > still inserts messages with empty > unique_ids during the insertion sequence. That should be fixed, if only be > wrapping this in a transaction. > Come to think of it, wouldn't transactions actually do?
Yep, transactions would do. I don't know if it was Aaron or me who rewrote all the other message insertion code to not add an empty unique id anymore. There is no problem in that code because the email is first delivered to the INTERNAL_DELIVERY_USER. Later a single atomic INSERT is done in the messages table. This INSERT copies the message information from the message inserted into the INTERNAL_DELIVERY_USER's mailbox to the recipient user's mailbox. db_imap_append_msg does *not* use this logic. It adds a entry into dbmail_messages, then adds the messageblocks, and finally finalizes the entry in dbmail_messages by adding a unique ID. I'll fix the function so the messageblocks are filled first, after which the message is added to the messages table, like this: 1. create physmessage 2. add messageblocks 3. add message The message will then get the right unique id directly, without having to change the unique_id later on. In fact, I don't think the unique_id of a message should ever be changed after having been set initially. Functions like db_message_set_unique_id() should therefor be removed, methinks.. I'll double check all this. I like removing code :) Ilja
