SA Bugzilla – Bug 4508
Missing feature in sql code for better Bayes/AWL support
Last modified: 2011-10-04 18:14:33 UTC
hi dev team, iam unning spamassassin 3.x (amavisd-new/sendmail-dual) setup on several boxes with great success. last friday i took a deeper look into the "new" sql support. first i was greatly exalted by the giving opportunitiy but then, after a short look into design, i start missing a feature with imho will be a pretty trivial problem. iam running simple mysql replication for amavisd-new sql features. the amavisd database will get replicated to each mailnode to safe time while reading from database. to get a powerfull AWL/Bayes db, i thought i could read from localhost and writing to master. but spamassassin just supports one dbh for now. it would be a great improvement and not much workes (patched it dirty in 10min) if you could add a seperate write handle to SpamAssassin/SQLBasedAddrList.pm / SpamAssassin/BayesStore/SQL.pm and local.cf. if no second handle is used, it should use the given handle for both read/write. because a read/write operation is done on each mailrequest this setup will have a double mysql connection as a disadvantage, but a powerfull AWL/Bayes sql db for all mailhosts as an advantage. to keep the write connections limited, iam thinking about a kind of "bin-log" were all AWL/Bayes inserts first get cached and sequential, maybe all 100 mails or via cron get dumped/restored into master database. maybe you have other ideas or comments for this issue but a second handler would be great for the start. what do you say? thanks for your time and great work, marc
Created attachment 3194 [details] Patch for sql read / write support Patches the following files: /usr/local/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/Conf.pm /usr/local/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/SQLBasedAddrList.pm /usr/local/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/BayesStore/SQL.pm
pls add to spamassassin if possible.
Created attachment 3739 [details] Much smaller patch for Bayes.
I'd like to see this too, like the original poster I've implemented this locally as well but the Bayes implementation is much easier since BayesStore already has a notion of opening the backend database in read or write mode; that concept just isn't honoured in the SQL backend.
(In reply to comment #4) > I'd like to see this too, like the original poster I've implemented this locally > as well but the Bayes implementation is much easier since BayesStore already has > a notion of opening the backend database in read or write mode; that concept > just isn't honoured in the SQL backend. Andy (sa@fiddaman.net), I realize it's been almost three years since you contributed that patch. Seems there is now some interest and an opportunity to fold it into the 3.3.0 release. Are you still around? Considering the patch size, we should probably need a CLA (Contributor License Agreements) from you: http://www.apache.org/licenses/ . Are you willing to provide it? Any updates on your submitted patch? Sorry for the nuisance, regards Mark (Mark.Martinec@ijs.si)
moving most remaining 3.3.0 bugs to 3.3.1 milestone
these were not supposed to go to security! moving back out of that component, but now probably to the wrong components :( , but better than nothing.
reassigning, too
moving all open 3.3.1 bugs to 3.3.2
Moving back off of Security, which got changed by accident during the mass Target Milestone move.