Очистить удаленное поле из базы данных


9

Я создал поля удалил их. Столы для полей исчезли после удаления, но они все еще находятся в field_configиfield_config_instance

Есть ли способ их почистить?

Спасибо

Ответы:


10

Записи в field_configи field_config_instance, вероятно, будут иметь значение 1в deletedстолбце.

Это означает, что они помечены для удаления, но на самом деле не будут удалены, пока вы не запустите cron (удаленные данные поля будут удалены field_cron()).


ты мужчина. У меня не был установлен phpmyadmin, поэтому я не проверял другие столбцы для этих двух таблиц через соединение ssh. спасибо Клайв
любитель спорта

11

используя drush:

$ drush eval "field_purge_batch(500)"

вам, возможно, придется запустить несколько раз или увеличить $ batch_size, тогда могут остаться таблицы field_deleted и field_deleted_revision, даже после запуска cron

запрос

SELECT * FROM `field_config` WHERE `deleted` = 1
SELECT * FROM `field_config_instance` WHERE `deleted` = 1

если вы пришли пустым, вы можете безопасно удалить эти оставшиеся таблицы


Это отличный ответ, спасибо @ decibel.places!
Joelpittet

6

В качестве альтернативы запуску cron для удаления удаленных данных вы можете вручную запустить field_purge_batch ($ batch_size) .

Чтобы вручную запустить функцию, вы можете:

  • Бутстрап Drupal в php файле
  • Создать обратный вызов страницы перехвата меню
  • Если у вас установлен модуль devel, посетите / devel / php

Используемый размер $ batch_size зависит от среды и потребностей вашего сервера. Я использовал значения от 5 до 10000.


4

Для тех пользователей Drupal 8,

Я испытал это также, копаю код. Я обнаружил, что все причины, по которым поля не были удалены после того, как вы это сделали, следующие:

  • выполнение cron gazillion раз
  • запустить drush eval "field_purge_batch (500)" миллион раз

Поля сохраняются, не исчезая, это из-за логики здесь, в field_purge_batch

  // We cannot purge anything if the entity type is unknown (e.g. the
  // providing module was uninstalled).
  // @todo Revisit after https://www.drupal.org/node/2080823.
  if (!isset($info[$entity_type])) {
    continue;
  }

Модули, являющиеся зависимыми, удаляются. это причина, почему поля не удаляются.

Как это решить? Рекомендуется сначала переустановить модуль, очистить эти поля и удалить обратно. Чтобы узнать, какой модуль необходимо переустановить:

$fields = entity_load_multiple_by_properties('field_config', array(
  'deleted' => TRUE,
  'include_deleted' => TRUE,
));
dpm($fields); // this is devel module of var_dump

// check the protected member called "dependencies"

В случае, если вы не хотите использовать этот метод переустановки модуля, вы также можете сразу же удалить, я не уверен, что такое поведение, но он должен делать свою работу.

Резервное копирование сначала !!!

Да, не ленитесь, это спасет вашу задницу, если что-то пойдет не так.

$fields = entity_load_multiple_by_properties('field_config', array(
  'deleted' => TRUE,
  'include_deleted' => TRUE,
));

foreach ($fields as $field) {
  $field->delete();
}

// Retrieve all deleted field storages. Any that have no fields can be purged.
$deleted_storages = \Drupal::state()->get('field.storage.deleted') ? : array();
foreach ($deleted_storages as $field_storage) {
  $field_storage = new FieldStorageConfig($field_storage);
  $fields = entity_load_multiple_by_properties('field_config', array('field_storage_uuid' => $field_storage->uuid(), 'include_deleted' => TRUE));
  if (empty($fields)) {
    field_purge_field_storage($field_storage);
  }
}

Сделай крона в последний раз. Я надеюсь, что это решит проблему :)


Добро пожаловать в ответы Drupal! Пожалуйста, не копируйте и не вставляйте один и тот же ответ на несколько вопросов. Если они являются дубликатами, отметьте их как дубликаты.
kiamlaluno

0

Не могу найти никакого решения. В итоге я удалил их из этих двух таблиц вручную.


Это тоже случилось со мной: создал поля на производстве, скопировал их в тестовую систему. Вернули поля в производство, снова скопировали в тестовую систему. Cron, вероятно, работает в то же время, поэтому, поскольку тестовая база данных не была должным образом удалена / воссоздана, две оставшиеся таблицы для данных и ревизий сохранились ... Выводы: * всегда запускать cron ДО создания резервной копии * при импорте в тестовую базу данных , всегда создавай и делай
Beat Christen

drupal.org/node/1351506 это все еще известная проблема.
Кевин Морс
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.