http://bugzilla.spamassassin.org/show_bug.cgi?id=3049





------- Additional Comments From [EMAIL PROTECTED]  2004-02-15 20:52 -------
Subject: Re:  Implement sa-learn --loaddb dumpfile functionality

On Sun, Feb 15, 2004 at 06:06:00PM -0800, [EMAIL PROTECTED] wrote:
> > 2) The few folks recently that needed this functionality had ham/spam
> >    counts < 0, this isn't right correct?  One of the things this does
> >    is sets any negative counts back to 0.
> 
> Sure.  A dbload functionality should look for (and be paranoid about)
> and try to fix any errors in the data it's loading.  For instance,
> I would ignore the magic tokens that were in the dump output and just
> make new ones from the tokens that were loaded.
> 

Yeah, this sounds good. I'll obviously need to keep the nspam and nham
tokens.  I can calculate the oldest/newest atimes and ntokens.  How
about the various sync/expire tokens?  Anyone see a problem with just
zeroing them out?

> 
> > 4) If not database version 2 then it won't work.
> 
> Not sure what you mean by this since you're creating the DB...  but don't
> hardcode v2.  Call BayesStore::_check_db_version().
> 

Yeah, I was thinking the data displayed would be bogus if it wasn't a
version 2 database, but perhaps this is the wrong assumption.  I'm
still gonna check and fail if it isn't.

> > 6) sa-learn isn't ARGV friendly it seems, so the dumpfile name has to
> >    be part of the --loaddb argument.
> 
> ??  I don't understand what you mean.  "loaddb=s" (in CmdLearn) would say
> that loaddb requires a string parameter.
> 

I guess what I meant was that it would have been convenient to be able
to do something like:
sa-learn -D --loaddb --showdots mydumpfile.txt
But it needs to be:
sa-learn -D --loaddb mydumpfile.txt --showdots
No big deal, I'm using loaddb=s to get the dumpfile name.

Michael





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to