On Wed, Oct 08, 2003 at 03:05:45PM +0200, 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
So does delete now just delete a record from messages, then check to see if any other messages refer to the physmessage, and if not delete the physmessage and associated messageblks? Are there any implications to having copy actually link rather than create another copy? IMAP doesn't have any concept of editing, right? So editing message creates a new message? I noticed you changed the column naming scheme with physmessage. It probably makes sense to make the column names consistent prior to the 2.0 release. (I prefer the singular table names, 'id' for primary key, and tablename_id for foreign key nomenclature used for the new phymessage table.) xn
