Niblett, David A wrote: > I just did a quick search and it would appear that MySQL > supports "ON DELETE CASACDE", so this should apply to both > MySQL and PostgreSQL, if my google source is correct. > > If you look in the create_tables.postgresql script in the > dbmail tree, you will notice that all the user_idnr foreign > key constraints have "ON DELETE CASCADE". I noticed that > the corresponding MySQL script does not have this, but the > MySQL InnoDB does have this feature. So maybe it's only > available in InnoDB. > > What it means is if the foreign key reference is removed, > the delete process will cascade through the database. (at > least that's my understanding.) > > So because I have this on all the user_idnr's and the message_idnr's > when I do a "delete from dbmail_users where user_idnr = 592" > the database takes care of deleting the aliases, mailboxes, > messages, physmessages and finally the actual user.
Aliases can not be maintained through cascades. There's no restraint on them. And I don't think dbmail-util cleans them up either. As there are more corner cases that are /not/ covered by dbmail-util at present. Also, since physmessages can belong to more than one message, there can be no cascades to physmessages by deleting messages either. But *that* one *is* covered by dbmail-util. So when you delete a user from dbmail_users you delete all mailboxes and associated messages. Physmessages and messageblks that become orphans are removable using dbmail-util. It's just the aliases you have to cleanout yourself. You /can/ of course declare a belongs-to relation between an alias and a user if you want to, but then you loose the ability to use forwards and commands in the aliases table. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
