Sorry, this got hung up in my drafts folder. The basic coding probably is solved, I think, but I'm worried we're not communicating about what the design problems are. So here goes.
Aaryan Bhagat writes:
Thanks for the reply, Stephen!
Stephen writes:
I don't understand why there's any problem here. In what scenario is the database corrupted relative to what is desired? What variables are set differently from desired, and how? What are the user consequences of the incorrect database?
What I mean is if we take the example of
BounceEvents
column which has all the bounce messages stored, after processing each message I have to set theprocessed
attribute of that message as true, so that will require modification of the database.Also in the case where I will be sending_warnings, there is warning_count and warning_limit ( not the exact names of the attributes ) of each
Address
instance with respect to eachMailing List
so I have to increase the warning_count counter and save again in the database.
I understand the details of the algorithm, that there are different attributes of certain objects that need to be modified.
I don't understand why you believe there are conditions under which Mailman will do something undesirable, such as create a very long delay from the time "something" (such as mailing a disabled warning) *should* happen until it *does* happen.