A BUGNOTE has been added to this bug. ====================================================================== http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000125 ====================================================================== Reported By: aaron Assigned To: aaron ====================================================================== Project: DBMail Bug ID: 125 Category: Database layer Reproducibility: always Severity: feature Priority: normal Status: assigned ====================================================================== Date Submitted: 27-Nov-04 12:53 CET Last Modified: 05-Feb-05 00:48 CET ====================================================================== Summary: ACL lookups are terribly inefficient Description: ACL lookups are done with one query per acl type. That means at least a dozen queries for each and every time you read a message or open a mailbox for a summary.
Rewriting the queries and some of the db_acl_* functions to select entire rows of acl's in one query would be much preferred. The temptation is then to cache the ACL values in a bitfield structure. Perhaps not so a bad an idea! ====================================================================== ---------------------------------------------------------------------- ilja - 29-Nov-04 10:45 CET ---------------------------------------------------------------------- FYI: When I first programmed the ACL code, I conciously made the decision to not make this extremely efficient. I wanted to have (somewhat) clean, working code first, and optimize later. There are a few ways in which this can be optimized. Getting all privileges for a user on a mailbox at once, and storing them in a bitfield seems like a very reasonable approach. I'm not completely sure on where to store this bitfield though. It could be a static variable in db_acl_has_right() for instance, but maybe we should try to avoid using statics.. ---------------------------------------------------------------------- aaron - 22-Dec-04 17:07 CET ---------------------------------------------------------------------- Added a listing of the functions which calls acl_has_right. When called three or four times in succession, a SELECT is done each time for a different column of the same row of the same table. ---------------------------------------------------------------------- OutboundIndex - 04-Feb-05 21:58 CET ---------------------------------------------------------------------- I have a special shared mailbox for multiple users to report missed spam back to me, such as [EMAIL PROTECTED] The users just set up an IMAP account in their Thunderbird, Eudora or Outlook and do a MOVE operation from their inbox to the junk@ IMAP folder in their email client. This works fine w/dbmail BUT I need to set permissions to "insert" only - so that users do not see any of the messages in the junk@ mailbox folder. They are all given the same user / pass. I set up an ACL table entry with the mailbox_idnr, the owner_idnr, and tried a 1 in the insert column. Seemed to have no effect on my ability to read messages in the folder from my email client. Tried a 5 in the insert column, still no effect. Any ideas what I need to do to prevent reading and allow only writing to this mailbox? - April ---------------------------------------------------------------------- aaron - 05-Feb-05 00:48 CET ---------------------------------------------------------------------- First try a 0 in the column read_flag. If that doesn't work, please follow up to the mailing list and not this bug -- it is specifcally a placeholder for a project I am working on to make ACL lookups more efficient. Bug History Date Modified Username Field Change ====================================================================== 27-Nov-04 12:53aaron New Bug 29-Nov-04 10:45ilja Bugnote Added: 0000381 22-Dec-04 17:06aaron File Added: imapacl.c 22-Dec-04 17:06aaron File Added: imapacls.c 22-Dec-04 17:06aaron File Deleted: imapacl.c 22-Dec-04 17:07aaron Bugnote Added: 0000461 04-Feb-05 21:58OutboundIndex Bugnote Added: 0000577 05-Feb-05 00:48aaron Bugnote Added: 0000578 ======================================================================
