Skip to main content
CiviCRM

Return to Answer

added 6 characters in body
Source Link
Joseph Lacey
Joseph Lacey
  • 171
  • 6

If I'm understanding correctly, I'd say there are two possible solutions here. The first is the easier one where you don't care about keeping the stats or history of the mailings in Civi. If that's case, then you can probably use the API explorer to delete old mailings, which would be equivalent to clicking to delete them from the Scheduled and Sent Mailings management list. This doesn't really archive them per se. You're just deleting them, but doing so through the explorer seems cleaner than deleting through the MySQL cli.

The second option is what my clients want which is to keep the stats and remove the bloat, but this currently doesn't exist as far as I know. The largest tables they have are civicrm_mailing_recipientscivicrm_mailing_recipients, civicrm_mailing_event_queuecivicrm_mailing_event_queue and civicrm_mailing_event_deliveredcivicrm_mailing_event_delivered. (The activity tables also get pretty big, but that's another issue.) I've schemed a solution that would require transferring the stats data to another table(s) to be able to reference them at a later date (not all that difficult), but hooking those new table(s) into the search functions, reports and other areas where it's needed is a taller order. I haven't really thought through this in any detail, so I'm sure there's lots I haven't considered. Maybe there's an interim solution between these two. Clicking Archive removes data from the some of the processing tables but keeps the stats tables in place?

If I'm understanding correctly, I'd say there are two possible solutions here. The first is the easier one where you don't care about keeping the stats or history of the mailings in Civi. If that's case, then you can probably use the API explorer to delete old mailings, which would be equivalent to clicking to delete them from the Scheduled and Sent Mailings management list. This doesn't really archive them per se. You're just deleting them, but doing so through the explorer seems cleaner than deleting through the MySQL cli.

The second option is what my clients want which is to keep the stats and remove the bloat, but this currently doesn't exist as far as I know. The largest tables they have are civicrm_mailing_recipients, civicrm_mailing_event_queue and civicrm_mailing_event_delivered. (The activity tables also get pretty big, but that's another issue.) I've schemed a solution that would require transferring the stats data to another table(s) to be able to reference them at a later date (not all that difficult), but hooking those new table(s) into the search functions, reports and other areas where it's needed is a taller order. I haven't really thought through this in any detail, so I'm sure there's lots I haven't considered. Maybe there's an interim solution between these two. Clicking Archive removes data from the some of the processing tables but keeps the stats tables in place?

If I'm understanding correctly, I'd say there are two possible solutions here. The first is the easier one where you don't care about keeping the stats or history of the mailings in Civi. If that's case, then you can probably use the API explorer to delete old mailings, which would be equivalent to clicking to delete them from the Scheduled and Sent Mailings management list. This doesn't really archive them per se. You're just deleting them, but doing so through the explorer seems cleaner than deleting through the MySQL cli.

The second option is what my clients want which is to keep the stats and remove the bloat, but this currently doesn't exist as far as I know. The largest tables they have are civicrm_mailing_recipients, civicrm_mailing_event_queue and civicrm_mailing_event_delivered. (The activity tables also get pretty big, but that's another issue.) I've schemed a solution that would require transferring the stats data to another table(s) to be able to reference them at a later date (not all that difficult), but hooking those new table(s) into the search functions, reports and other areas where it's needed is a taller order. I haven't really thought through this in any detail, so I'm sure there's lots I haven't considered. Maybe there's an interim solution between these two. Clicking Archive removes data from the some of the processing tables but keeps the stats tables in place?

Source Link
Joseph Lacey
Joseph Lacey
  • 171
  • 6

If I'm understanding correctly, I'd say there are two possible solutions here. The first is the easier one where you don't care about keeping the stats or history of the mailings in Civi. If that's case, then you can probably use the API explorer to delete old mailings, which would be equivalent to clicking to delete them from the Scheduled and Sent Mailings management list. This doesn't really archive them per se. You're just deleting them, but doing so through the explorer seems cleaner than deleting through the MySQL cli.

The second option is what my clients want which is to keep the stats and remove the bloat, but this currently doesn't exist as far as I know. The largest tables they have are civicrm_mailing_recipients, civicrm_mailing_event_queue and civicrm_mailing_event_delivered. (The activity tables also get pretty big, but that's another issue.) I've schemed a solution that would require transferring the stats data to another table(s) to be able to reference them at a later date (not all that difficult), but hooking those new table(s) into the search functions, reports and other areas where it's needed is a taller order. I haven't really thought through this in any detail, so I'm sure there's lots I haven't considered. Maybe there's an interim solution between these two. Clicking Archive removes data from the some of the processing tables but keeps the stats tables in place?