¿Cómo agrego valores predeterminados a una tabla de base de datos usando hook_install ()?

9

Estoy creando un módulo personalizado con su propio esquema de algunas tablas. Estas tablas deben tener algunos valores rellenados previamente para que el módulo funcione (ubicaciones predeterminadas, opciones seleccionadas, etc.).

¿Cuál es la mejor forma de insertar valores predeterminados en estas tablas durante hook_install?

Como drupal_write_record no está disponible, puedo usar db_query, pero solo quiero asegurarme de que no estoy rompiendo ninguna regla cardinal al hacerlo.

naranjas13
fuente

Respuestas:

7

La mejor manera es hacerlo dentro de hook_enable () ; en el momento en que se invoca el gancho, el módulo ya está instalado y el esquema de su base de datos está disponible para Drupal y para drupal_write_record(). Como el gancho se invoca todas las veces que se habilita un módulo, y no solo cuando el módulo está instalado, la implementación del gancho debe verificar si ya no agregó esas filas de la base de datos (por ejemplo, debe usar una variable Drupal que contenga un valor booleano) .

Como ejemplo de módulo que se usa hook_enable()para un propósito similar, puede verificar forum_enable () o php_enable () (que agrega el formato de entrada "código PHP").

function php_enable() {
  $format_exists = (bool) db_query_range('SELECT 1 FROM {filter_format} WHERE name = :name', 0, 1, array(':name' => 'PHP code'))->fetchField();
  // Add a PHP code text format, if it does not exist. Do this only for the
  // first install (or if the format has been manually deleted) as there is no
  // reliable method to identify the format in an uninstall hook or in
  // subsequent clean installs.
  if (!$format_exists) {
    $php_format = array(
      'format' => 'php_code', 
      'name' => 'PHP code',
      // 'Plain text' format is installed with a weight of 10 by default. Use a
      // higher weight here to ensure that this format will not be the default
      // format for anyone. 
      'weight' => 11, 
      'filters' => array(
        // Enable the PHP evaluator filter.
        'php_code' => array(
          'weight' => 0, 
          'status' => 1,
        ),
      ),
    );
    $php_format = (object) $php_format;
    filter_format_save($php_format);

    drupal_set_message(t('A <a href="@php-code">PHP code</a> text format has been created.', array('@php-code' => url('admin/config/content/formats/' . $php_format->format))));
  }
}

Como se muestra en esas implementaciones de gancho, el código podría necesariamente ejecutarse todo el tiempo que se ejecuta el gancho; también podría ser que el código necesita ejecutarse una sola vez, ya que en el caso de que los valores predeterminados agregados a la base de datos no puedan ser alterados por el usuario, que no tiene una interfaz de usuario para alterar / eliminar esos valores.

kiamlaluno
fuente
Si hice esto en hook_enable (), eso significa que los valores predeterminados se restablecerían cada vez que el módulo esté habilitado y deshabilitado. Creo que eso es bastante común, en lugar de desinstalar y reinstalar por completo (en ese momento, se espera que la base de datos se restablezca).
naranjas13
1
Es por eso que escribí, "la implementación del gancho debería verificar si ya no agregó esas filas de la base de datos". Esto significa que debe verificar si los valores ya están en la tabla de la base de datos, o usar una variable Drupal para verificar si ya ha realizado esa tarea. Se verificaría la tabla de la base de datos si esos valores necesariamente tienen que estar en la base de datos; por ejemplo, este es el caso si se requieren los valores del módulo y los usuarios no pueden eliminar los valores predeterminados.
kiamlaluno
Gracias por la aclaración. ¿Hay alguna diferencia en el almacenamiento de estos valores en mi propia tabla personalizada en comparación con el uso de variable_set para almacenarlos en una variable persistente? Es solo una matriz de valores para cuadros de selección personalizados.
naranjas13
Todos los valores establecidos con variable_set(), que no se eliminan variable_del(), se cargan en la memoria cuando se inicia Drupal y se guardan en una variable global; Esto significa que están en la memoria, sea cual sea el módulo que esté utilizando esos valores, o no. Con una tabla de base de datos personalizada, puede estar seguro de que esos valores solo se cargan cuando el módulo realmente lo necesita. No debe usar variable_set()si la variable Drupal contiene una matriz a la que sigue agregando un nuevo índice de matriz todo el tiempo, por ejemplo.
kiamlaluno
Mirando el código (D7). Solo veo 2 líneas de código entre la invocación de hook_install y hook_enable: una actualización de una variable local y una llamada a watchdog. Por lo tanto, durante una instalación real, no hay diferencia alguna entre estos 2 ganchos sobre lo que está disponible y registrado y lo que no. La única diferencia es si se trata de una instalación por primera vez o si solo se vuelve a habilitar el módulo.
fietserwin
4

Iría con db_query/ db_insert(D6 / D7) en hook_install ().

No se considera una mala práctica (y nadie te obliga a usar drupal_write_record()).

No es raro que las personas deshabiliten y vuelvan a habilitar los módulos, y en ese caso su código hook_enable()se disparará cada vez. lo cual no es bueno

Bojan Zivanovic
fuente