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.

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.

  • No modules have been disabled since this appeared. – beth Jun 21 '13 at 19:13
  • Also, deleting the tables manually leads to PDOExceptions. – beth Jun 24 '13 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.

  • 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 Jun 18 '13 at 16:52
  • Use drush drush field-delete deleted_date_N --bundle=content_type – Interlated Jun 19 '13 at 11:05
  • That didn't do anything, even after correcting the typos. – beth Jun 19 '13 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. – Bojan Zivanovic Jun 20 '13 at 14:49
  • @BojanZivanovic If you get a chance put that in as an answer – Clive Jun 20 '13 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)));
    }

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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