Limpiar campo eliminado de la base de datos

9

He creado campos eliminándolos. Las tablas para los campos se han ido al eliminar, pero todavía están en field_configyfield_config_instance

¿Hay alguna forma de limpiarlos?

Gracias

lusketeer
fuente

Respuestas:

10

Las entradas en field_configy field_config_instanceprobablemente hayan tenido un valor de 1en la deletedcolumna.

Esto significa que están marcados para su eliminación, pero en realidad no se eliminarán hasta que ejecute cron (los datos de campo eliminados se eliminan field_cron()).

Clive
fuente
tu eres el hombre. No tenía phpmyadmin instalado, así que no verifiqué otras columnas para esas dos tablas a través de la conexión ssh. gracias Clive
lusketeer
11

usando drush:

$ drush eval "field_purge_batch(500)"

es posible que deba ejecutar algunas veces, o aumentar el tamaño de $ batch_size, entonces aún puede haber tablas field_deleted y field_deleted_revision, incluso después de ejecutar cron

consulta

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

si aparece vacío, puede eliminar de forma segura esas tablas sobrantes

decibelios.
fuente
Esta es una gran respuesta, gracias @ decibel.places!
joelpittet
6

Como alternativa a ejecutar cron para eliminar datos eliminados, puede ejecutar manualmente field_purge_batch ($ batch_size) .

Para ejecutar manualmente la función, puede:

  • Bootstrap Drupal en un archivo php
  • Crear una devolución de llamada de página de enlace de menú
  • Si tiene instalado el módulo de desarrollo, visite / devel / php

El $ batch_size a usar variará según el entorno y las necesidades de su servidor. He usado valores tan bajos como 5 y tan altos como 10000.

Cody Craven
fuente
4

Para aquellos usuarios de Drupal 8,

También experimenté esto, desenterrar el código. Encontré todo esto por qué los campos no se eliminan después de que lo hizo, lo siguiente:

  • ejecutando cron millones de veces
  • ejecutar drush eval "field_purge_batch (500)" millones de veces

Los campos son persistentes y no desaparecen, esto se debe a una lógica aquí, en 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;
  }

Los módulos dependientes se desinstalan. esa es la razón por la cual los campos no se eliminan.

¿Cómo resolver esto? Se recomienda un enfoque para reinstalar el módulo primero y purgar esos campos y desinstalar nuevamente. Para averiguar qué módulo necesita reinstalar:

$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"

En caso de que no quiera seguir ese enfoque de reinstalar el módulo, también puede eliminarlo de inmediato, no estoy seguro de cuál es el comportamiento, pero debería hacer el trabajo.

Copia de seguridad primero !!!

Sí, no seas perezoso, te salvará el culo si algo sale mal.

$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);
  }
}

Haz el cron por última vez. Espero que solucione el problema :)

kororo
fuente
¡Bienvenido a Drupal Answers! No copie y pegue la misma respuesta para varias preguntas. Si son duplicados, márquelos como duplicados.
kiamlaluno
0

Parece que no puedo encontrar ninguna solución. Así que terminé eliminándolos de esas dos tablas manualmente.

lusketeer
fuente
Esto también me sucedió a mí: creé campos en producción, los copié al sistema de prueba. Revertió los campos en producción, copiado nuevamente al sistema de prueba. Cron probablemente se ha ejecutado mientras tanto, por lo tanto, dado que la base de datos de prueba no se eliminó / recreó correctamente, las dos tablas sobrantes de datos y revisiones se mantuvieron ... Hallazgos: * siempre ejecuta cron ANTES de realizar una copia de seguridad * al importar a una base de datos de prueba , siempre suelta y crea
Beat Christen
drupal.org/node/1351506 esto sigue siendo un problema conocido.
Kevin Morse