http://bugzilla.spamassassin.org/show_bug.cgi?id=3049
------- Additional Comments From [EMAIL PROTECTED] 2004-02-15 18:05 ------- Subject: Re: Implement sa-learn --loaddb dumpfile functionality On Sun, Feb 15, 2004 at 05:50:39PM -0800, [EMAIL PROTECTED] wrote: > 1) Right now it creates a whole new database file and instructs the > user to copy it into place to start using it. Should it go ahead > and do the copy for them? or let the user do it just in case? IMO it should make the new DB file, ala expiry et al, and if everything succeeds, move the old one out of the way and rename the new one. > 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. > 3) Related to number 2, folks have atimes way in the future, if the > atime is > time() then I go ahead and set it to time(). Sure. > 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(). > 5) All of the required "magic" variables must be found in the dumpfile > otherwise it is considered an error and bails out. Per #2 above, I'd just ignore the magic variables. > 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
