Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I am cleaning up some tables for our final migration to D7 and have found the deleted tables that have over 218000 entries for the oa_delete bundle. Is this used in oa sandbox? If so, will disabling the sandbox module clear the table entries?
Comments
Comment #1
hollyfox CreditAttribution: hollyfox commentedComment #2
mpotter CreditAttribution: mpotter commentedCan you be more specific about what table you are talking about? I don't see any deleted tables. oa_delete is a bundle of the message entity.
The Message API module has rules for how long deleted messages are kept, so check the /admin/config/system/message page for that. By default the auto-purge option is disabled, so nothing gets removed.
Disabling the sandbox module won't have any effect unless you have sandbox mode enabled, in which case it just marks nodes as temporary and deletes them when sandbox mode is disabled. Just having the module enabled doesn't do anything.
Comment #3
hollyfox CreditAttribution: hollyfox commentedThanks for the quick response. The tables I refer to are the field_data_field_deleted_summary and field_data_field_deleted_title. I went to the page you suggested and set it to purge. What event makes these purge? I am going to run cron to see if that does it. Ultimately, I am just trying to get a clean database before I migrate the final time for production.
Comment #4
mpotter CreditAttribution: mpotter commentedWhen you click the Purge checkbox in the Message settings you'll see two other fields. The first one lets you specify how many messages you want to keep. The second one lets you specify how many days you want to keep messages. I recommend the second option and just set that to how many days you want your Recent Activity to show activity.
It should be running during cron, but it also has a limit of only purging 100 messages per cron run to prevent cron from being too slow. This is stored in a variable "message_delete_cron_limit" so you can set this via Drush:
drush vset message_delete_cron_limit 218000
to let it delete 218,000 entries. But this will obviously take a really long time.
If you have a developer with knowledge of drush and how pull-requests and patches work, there is a pull request for the Message module to provide a drush command to bulk-delete old messages here: https://github.com/Gizra/message/pull/23
Comment #5
hollyfox CreditAttribution: hollyfox commentedThank you. Interestingly, I am the only developer here and am familiar with Drush. I do know that the entries in these tables do not match up with any node entries or revisions entries so I presume that they are orphaned and may need to be removed manually. I just want to be sure I am not messing something else up. I am going to see about getting the pull for the drush command. If that does not do it, it will be obvious that they are just isolated entries.
Thank you for your help with this. I will report back to let you know how it went.
Comment #6
mpotter CreditAttribution: mpotter commentedThese are fields on the Message entity, not on Nodes. The oa_delete message bundle needs to store the original title and summary of any deleted node so it can be shown in the Recent Activity listing. That's what these fields are storing. You could probably just truncate these tables but then you probably also have a ton of entries in the Message table also.
Comment #7
hollyfox CreditAttribution: hollyfox commentedOK, I see that they correspond to message entities. I have resolved to let the system purge them since I will be off for 5 days and they should be gone by then. I created a php script to look for orphaned table entries for each bundle and was able to remove all of these with it, but I will wait for the system to get rid of them and then it is on to the migration sprints.
Thanks for your help and hopefully we will be up and running by the end of July!