http://bugzilla.spamassassin.org/show_bug.cgi?id=3331
------- Additional Comments From [EMAIL PROTECTED] 2004-04-29 09:58 ------- Michael Parker wrote: > It has all sorts of implications, not just database format. And yes, > it would need to be a config option. Default off, of course. > 1) How do you handle backup/restore? I don't see the issue, other than having to add code to write or read the original token. > > 2) Where are you going to put this data? In a seperate db file/table > or alongside the current data? Be careful, your answer may require > a ton more work. I'd put the original token in the same record used to hold the other information (num ham, num spam, atime). I'm assuming db_file and SQL can handle a variable-length string field and that their implementations do so in a reasonable manner. (That is, there would be no big performance difference between a table without variable-length string fields and one with a string field that only stores nulls.) For a new token an original token (OT) field would be initialized to the token or to a null, depending on the option. When reading a token the OT field would be ignored if the OT option were off. The OT data would only be used for statistics, so its absence would not affect normal operation. Turning the option on and off should present no problems because there is no change in database format. There are several ways of dealing with the stored tokens when the option is turned off. One is to immediately delete all the tokens. (Time consuming, especially for someone who turned OT off by accident.) Instead of immediately deleting the tokens a separate "wipe tokens" command could be provided. I'm assuming the OT option would only be kept by those who know what they're doing, and so the slight complication of a separate "wipe tokens" command is acceptable. > > 3) Maintenance issues. That's why the original token is a data field, and not a key. > 4) How do you handle the case where someone has this option turned > off, but then turns it on? See above. > > Patched welcome of course. I don't have SQL installed so there is no way I could test any changes for that back end. If no one else starts working on the changes in a few days I'll make them for dbfile (DBM). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
