On Wednesday, Oct 8, 2003, at 16:07 Europe/Amsterdam, Magnus Sundberg
wrote:
Ilja Booij wrote:
* extra table
There is an extra table in the database (physmessage, for 'physical
message', as opposed to virtual message) which links messageblocks
and messages. This gives us great speed up with regard to copying
messages. In the old database scheme, copying a message meant copying
all messageblocks, which is slow. Now, only a new entry in the
messages table has to be made, which points to the same physmessage
record.
This speed up was needed because copying occurs quite frequently;
IMAP has no MOVE command, so a move is done by a COPY followed by a
delete. This occurs often, for instance when a client does not really
delete, but moves a message to the Trash folder
The messages tables has been changed like this: it holds an extra
physmessage_id field. The messagesize, rfcsize and internal_date
fields have
been removed.
the physmessage table holds: messagesize, rfcsize and internal_date
the messageblks table now holds a physmessage_id instead of a
message_idnr
This is probably a stupid question, but:
I do not understand the database structure now, can someone please
clarify the operation.
You have several database definitions, where you state FOREIGN KEY ...
REFERENCES ... ON DELETE CASCADE.
This is in the innodb part.
Well suppoe I do a move from folder A to folder B.
The record in the messages table is copied to also reference folder B.
Next the message record that references folder A is deleted,
Well everything works all right, because the physmessage does not
contain a foreign key reference.
But what happens if an ordinary user choses to actually delete a
message. How do you know that it is not referenced anywhere else?
How do you delete messageblks records?
When a message is deleted only the record in the messages table is
removed. Then, it is checked whether there are any messages referencing
the same
physmessage record. If not, the physmessage and messageblks can be
deleted.
cheers,
ilja
