Cron should clear og2list_outgoing_content table
| Project: | Organic groups list manager |
| Version: | HEAD |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
I do not know if this is intended behavior, but it surely seems fishy.
In the course of operating og2list I am finding that og2list_outgoing_content table is not cleaned up after an outgoing email is sent out (unlike og2list_outgoing_arguments and og2list_outgoing_recipients). Quick search of mail-out.pl and og2list.module shows that no code anywhere issues a DELETE statement against this table.
Is there any reason to keep the contents of the table after email is sent? I cannot think of any. The question equally applies to og2list_msgid table.
What should be the right behavior? We need to either fix the code to clean up these tables or document why it is preserved and how it is used.
Same issue for HEAD / 5.1...

#1
OK, I did some research and looks like this table's content does not need to be kept indefinitely.
However, conditions for clearing is somewhat complicated. Table is populated when a node is posted to a group, then it is picked by Perl script in two passes. The data is really no longer needed only when ALL of the following tables are empty:
- og2list_incoming_content
- og2list_incoming_groups
- og2list_outgoing_arguments
- og2list_outgoing_recipients
So here is the suggested implementation for clean up within Cron:
1) Lock all of the above tables
2) Run counts to check if they are all empty
3) If they are delete all data in og2list_outgoing_content
Would anyone see a problem with this approach or should it be implemented ?
#2
actually the incoming tables are independent from the outgoing tables.
What happens is mails go into og2list_outoging_content from og2list_send_mail. Then the first pass of mail-out.pl creates the rows in og2list_outgoing_recipients. The second pass of mail-out.pl then sends out the mails and deletes the rows from og2list_outoging_recipients - but the rows in og2list_outoging_content remain.
I suspect there probably was reasoning behind doing it that way, possibly it is the digest mode? For digests to work, mail-out.pl has to be called twice from cron, once with the "-d" switch and once without. if "-d" is present, then mail-out.pl runs a whole bunch of different logic (the top side of an if / then / else). This top digest logic builds up the body of an email for each user with all the day's messages (they come from og2list_outgoing_content). Then the bottom part of the if/then/else is for regular mode where you receive an individual mail.
Depending on what frequency you wanted for your digest, you could schedule mail-out.pl -d to run once a day, once a week, etc.
So as a rule of thumb it should be safe to delete old mail after the digest period, whatever the frequency of the cron job is set to. But in the code we can't know that so......
I'm really not sure what the best way to proceed is. Obviously just leaving them and letting them fill up is no good. Maybe we can have each -d run delete the old content from the previous runs? That might work, if we can do it... someone will have to take a look and see what if any SQL would do the trick.
but without implementing that I think we're stuck leaving the data in there for now.