Michael Monnerie wrote:
On Sonntag 22 Februar 2009 Paul J Stevens wrote:
this has already been fixed in 2.3:
Yes, but could/should be in 2.2 too...? I think 2.2 will be used for
quite a long time still, as 2.3 is development state, and after becoming
2.4.0 needs to settle a bit before we are able to use it in production.
2.2. is dead from a development perspective. As far as I can tell this
issue is a performance hack. If you really need this: submit a patch :-)
Ah, 2.3 keeps the mailboxes until "dbmail-util -p", right?
Not quite. That only applies for mailboxes that contain child mailboxes.
Why is it different: once you delete a mailbox and once you mark it
no_select? Wouldn't the same schema all the time be better? I'd prefer
keeping all mailboxes until after a "dbmail-util -p", to keep support
from end users low ("I've deleted my mailbox". "OK, here is it
restored". "Yeah, great support!").
Possible, but far from trivial. Consider:
x DELETE mymailbox
x CREATE mymailbox
is a perfectly valid imap command sequence. That would imply renaming
such mailboxes into a 'attic'-like namespace, or else the create command
would fail. Like I said, doable, but not trivial.
You seem to be making a loop and then two updates per mailbox. Why not
doing it all in one statement? The database is always faster with single
commands, should be fine like:
UPDATE dbmail_mailboxes SET no_select = 1 WHERE mailbox_idnr IN (SELECT
mailbox_idnr WHERE name like 'mbx/to/delete%');
UPDATE dbmail_messages SET status=PURGE WHERE mailbox_idnr IN (SELECT
mailbox_idnr WHERE name like 'mbx/to/delete%');
Yuk. IMAP-DELETE commands are always mailbox specific. Glob patterns are
evil in that context, afaict.
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
