Bug 4508 - Missing feature in sql code for better Bayes/AWL support
Summary: Missing feature in sql code for better Bayes/AWL support
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 3.0.4
Hardware: All All
: P4 normal
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-30 11:26 UTC by Marc Sztochay
Modified: 2011-10-04 18:14 UTC (History)
2 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Patch for sql read / write support patch None andeman [NoCLA]
Much smaller patch for Bayes. patch None sa@fiddaman.net [NoCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Sztochay 2005-07-30 11:26:08 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
Comment 1 andeman 2005-10-18 08:00:13 UTC 
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
Comment 2 Marc Sztochay 2005-10-18 08:06:58 UTC 
pls add to spamassassin if possible.
Comment 3 sa 2006-11-01 13:04:35 UTC 
Created attachment 3739 [details]
Much smaller patch for Bayes.
Comment 4 sa 2006-11-01 13:05:44 UTC 
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.
Comment 5 Mark Martinec 2009-11-17 08:20:12 UTC 
(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)
Comment 6 Justin Mason 2010-01-27 02:19:56 UTC 
moving most remaining 3.3.0 bugs to 3.3.1 milestone
Comment 7 Justin Mason 2010-01-27 03:14:57 UTC 
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.
Comment 8 Justin Mason 2010-01-27 03:15:24 UTC 
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.
Comment 9 Justin Mason 2010-01-27 03:16:04 UTC 
reassigning, too
Comment 10 Justin Mason 2010-03-23 16:32:56 UTC 
moving all open 3.3.1 bugs to 3.3.2
Comment 11 Karsten Bräckelmann 2010-03-23 17:42:20 UTC 
Moving back off of Security, which got changed by accident during the mass Target Milestone move.