You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Walter Hurry <wa...@gmail.com> on 2013/03/19 20:22:49 UTC

Bayes - Problem using SQLite

I am experimenting with using SQLite for my Bayes db.

However when I start spamd, it reports the following in /var/log/maillog:

bayes: tok_get_all: SQL error: no such function: RPAD

This is correct, in that SQLite does not support RPAD.

I believe this call is in SQL.pm (part of Mail::SpamAssassin::BayesStore).
Is it possible to hack that module in any way to work around the issue?

Sorry if this is too simple a question; whilst I am familiar with SQL, I
know nothing of perl.

In case it matters, this is SA 3.3.2



Re: Bayes - Problem using SQLite

Posted by Walter Hurry <wa...@gmail.com>.
On Tue, 19 Mar 2013 19:31:44 +0000, Jeremy McSpadden wrote:

> SQLite is/can-be extremely slow with inserts/updates. It uses a
> temporary file for each write operation. It also waits for the OS to
> complete the insert/update. … Thats all assuming you can even get it
> working.

It's working fine when I use spamassassin; it's just that I see this 
error in /var/log/maillog when I try to use spamc/spamd


Re: Bayes - Problem using SQLite

Posted by Jeremy McSpadden <je...@fluxlabs.net>.
SQLite is/can-be extremely slow with inserts/updates. It uses a temporary file for each write operation. It also waits for the OS to complete the insert/update. … Thats all assuming you can even get it working.

--
Jeremy McSpadden
Flux Labs, Inc | http://www.fluxlabs.net<http://www.fluxlabs.net/> | Endless Solutions
Office : 850-250-5590x101<tel:850-250-5590;101> | Cell : 850-890-2543<tel:850-890-2543> | Fax : 850-254-2955<tel:850-254-2955>

On Mar 19, 2013, at 2:22 PM, Walter Hurry <wa...@gmail.com>>
 wrote:

I am experimenting with using SQLite for my Bayes db.

However when I start spamd, it reports the following in /var/log/maillog:

bayes: tok_get_all: SQL error: no such function: RPAD

This is correct, in that SQLite does not support RPAD.

I believe this call is in SQL.pm (part of Mail::SpamAssassin::BayesStore).
Is it possible to hack that module in any way to work around the issue?

Sorry if this is too simple a question; whilst I am familiar with SQL, I
know nothing of perl.

In case it matters, this is SA 3.3.2





Re: Bayes - Problem using SQLite: SOLVED

Posted by Walter Hurry <wa...@gmail.com>.
On Thu, 21 Mar 2013 03:07:44 +0000, Walter Hurry wrote:

> On Tue, 19 Mar 2013 19:22:49 +0000, Walter Hurry wrote:
> 
>> I am experimenting with using SQLite for my Bayes db.
>> 
>> However when I start spamd, it reports the following in
>> /var/log/maillog:
>> 
>> bayes: tok_get_all: SQL error: no such function: RPAD
>> 
>> This is correct, in that SQLite does not support RPAD.
>> 
>> I believe this call is in SQL.pm (part of
>> Mail::SpamAssassin::BayesStore).
>> Is it possible to hack that module in any way to work around the issue?
>> 
>> Sorry if this is too simple a question; whilst I am familiar with SQL,
>> I know nothing of perl.
>> 
>> In case it matters, this is SA 3.3.2
> 
> It looks to be solved by hacking SQL.pm. I'll report back in a day or so
> in case anyone is interested.

Yes, I changed the (SQL.pm) line in sub _token_select_string
from:
return "RPAD(token, 5, ' ')";
to:
return "SUBSTR(token || '     ', 1, 5)";

and all seems to be working according to plan now.


Re: Bayes - Problem using SQLite: SOLVED

Posted by Walter Hurry <wa...@gmail.com>.
On Tue, 19 Mar 2013 19:22:49 +0000, Walter Hurry wrote:

> I am experimenting with using SQLite for my Bayes db.
> 
> However when I start spamd, it reports the following in
> /var/log/maillog:
> 
> bayes: tok_get_all: SQL error: no such function: RPAD
> 
> This is correct, in that SQLite does not support RPAD.
> 
> I believe this call is in SQL.pm (part of
> Mail::SpamAssassin::BayesStore).
> Is it possible to hack that module in any way to work around the issue?
> 
> Sorry if this is too simple a question; whilst I am familiar with SQL, I
> know nothing of perl.
> 
> In case it matters, this is SA 3.3.2

It looks to be solved by hacking SQL.pm. I'll report back in a day or so 
in case anyone is interested.