4

I am running a site on D7. I noticed a no. of field_deleted_data_N and field_deleted_revision_N tables in my database. Through a lot of googling I found people saying that these tables will eventually be cleared on cron run. They also said you could run field_purge_batch().

However neither of there suggestions worked. Could somebody please help me solve this problem? Why are these fields never removed? Is there something wrong with my database? How can I remove them in a drupallish manner?

Thanks.

3 Answers 3

2

If drush doesn't help and running cron doesn't help, that might mean that the field data can't be purged because the module providing the field type has been disabled and / or uninstalled. In that case just drop the tables manually.

2
  • No modules have been disabled since this appeared.
    – beth
    Commented Jun 21, 2013 at 19:13
  • Also, deleting the tables manually leads to PDOExceptions.
    – beth
    Commented Jun 24, 2013 at 21:03
0

There is probably content in them. Drupal tries to play it safe and not remove fields that may result in lost data.

Use drush:

drush field-delete deleted_date_N --bundle=content_type

Other things to try that I have also found to be of varying success:

The status report sometimes gives you hints why. Reports -> Status report. This report will let you 'run cron manually' and run the 'database update script'.

The database update script triggers update functions which you can try. I have found it is still far more 'safe' than drush.

Put it in a module .install file.

function hottopicsnotify_update_7002() {
  // Clear cache first?

  field_delete_field('field_effect');

  field_purge_batch();
}

This can also be run via drush:

drush updb

I have run 'drop table' in sql with varying success - I don't recommend it. Drush field-delete is the way to go.

6
  • The OP specifically said that running field_purge_batch() isn't working. I'm also encountering the same issue, and when I try to use .intall as you suggest, field_delete_field() can't do its stuff because of the deleted data tables already existing. Oh, and I made sure that the deleted data tables were empty before running cron.
    – beth
    Commented Jun 18, 2013 at 16:52
  • Use drush drush field-delete deleted_date_N --bundle=content_type
    – Interlated
    Commented Jun 19, 2013 at 11:05
  • That didn't do anything, even after correcting the typos.
    – beth
    Commented Jun 19, 2013 at 16:05
  • 1
    If drush doesn't help and running cron doesn't help, that means that the field data can't be purged because the module providing the field type has been disabled and / or uninstalled. So just drop the tables manually. Commented Jun 20, 2013 at 14:49
  • @BojanZivanovic If you get a chance put that in as an answer
    – Clive
    Commented Jun 20, 2013 at 16:49
0

This has become quiet a nuisance for me. I modified the renameTable function schema.inc in includes/database/mysql to return FALSE rather than throw exceptions for these conditions (which is more inline with the way the rest of the schema.inc code handles [exists|!exists] situations...

 public function renameTable($table, $new_name) {
if (!$this->tableExists($table)) {
  return FALSE;
//      throw new DatabaseSchemaObjectDoesNotExistException(t("Cannot rename @table to @table_new: table @table doesn't exist.", array('@table' => $table, '@table_new' => $new_name)));
    }
    if ($this->tableExists($new_name)) {
      return FALSE;
//      throw new DatabaseSchemaObjectExistsException(t("Cannot rename @table to @table_new: table @table_new already exists.", array('@table' => $table, '@table_new' => $new_name)));
    }
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.