Right, and if a new user got assigned the id of an old user then all of the old users data would be exposed to the new user. I understand this shouldn't happen under normal circumstances but that is the consequence if it happens somehow.
As for using foreign keys to do the delete work for you, I agree that I don't want to mistakenly delete everything and that I do want to be warned before it does anything. I think the maintenance program that removes the account should check to see if the user exists, if there are any messages etc and then warn the person running the script that they are about to delete an account that still has X mailboxes and Y messages etc, and ask for confirmation. Furthermore you could prompt for a second confirmation after doing the delete and rollback the transaction if the admin denies the second confirmation. I agree that the tools should work to prevent you from shooting yourself in the foot, but I think the database should do as much as it can to keep itself consistent. I know we have a maintenance script that helps with these issues, but that is treating the symptom, not fixing the problem. Matthew > Correct, the new user will be assigned a new id number, despite having > the same user name. Since the messages are linked by id number rather > than name, the new user doesn't see the messages which used to belong to > the old user of the same name. > > As for the old messages, I believe that dbmail-maintenance will delete > them for being unconnected, and so the space will be reclaimed anyhow. I > believe that the major issue here is that there are any number of > situation / administrators who wouldn't want to delete a user if they > still had mail in their account, either because they don't want to face > killer typos (ie. same reason many people alias mv, cp and rm with -i) > or because you might want to expire a large number of older accounts, > but keep the ones that are still being used actively (although there are > other better ways to do this, I believe in having tools that aid in > consistency as much as having administrators adhere to consistent > policy). > > Aaron > > > On Tue, 17 Jun 2003, Jacques Beaudoin wrote: > >> After doing some test. >> >> I think that if you delete a user that as messages in the tables and >> recreate that user the newly recreate user will not se is old >> messages. >> >> So why be so fussy about deleting messages that belongs to nobody. >> >> Jacques >> >> >> Aaron Stone a écrit : >> >> > On the other hand, it wouldn't take a lot of code or any significant >> overhead to run a few queries to see what the user has in the >> database. Further, I believe that in a data-destroying operation >> like this, there should be a warning message by default and a >> --force option if you really don't want to hear about it ;-) >> > >> > Aaron >> > >> > On Tue, 17 Jun 2003, Matthew T. O'Connor wrote: >> > >> > > > If i delete a user is aliases are not deleted thats not a big >> problem i just delete via a script is aliases (dbmail-aduser c >> user -a aliases) before i delete that user. >> > > > >> > > > But what about is old mailboxes and messages in the >> > > > mailboxes, messages, messageblks tables. >> > > >> > > I would think this is best handled via referential integrity from >> the database. I added all the foreign key relationships that seem >> relevant to >> > > my postgres setup, this guarantees that everthing associated with >> the >> > > user gets deleted when the user is deleted (or won't let you >> delete the user while there is data dependentand on the user, >> depending on how the foreign key was setup). >> > > >> > > >> > > _______________________________________________ >> > > Dbmail mailing list >> > > [email protected] >> > > https://mailman.fastxs.nl/mailman/listinfo/dbmail >> > > >> > _______________________________________________ >> > Dbmail mailing list >> > [email protected] >> > https://mailman.fastxs.nl/mailman/listinfo/dbmail >> >> _______________________________________________ >> Dbmail mailing list >> [email protected] >> https://mailman.fastxs.nl/mailman/listinfo/dbmail >> > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail
