drush updatedb pour un seul module

28

Est-il possible d'effectuer la fonction de mise à jour d'un seul module via drush? Je peux voir drush updatedblequel ne prend pas un nom de module comme argument et exécute toutes les mises à jour disponibles. Il y a ensuite drush pm-updatequi vérifie également les nouveaux fichiers. la documentation dit:

(identique à pm-updatecode + updatedb)

Est-ce à dire que si drush pm-updatej'exécute toutes les mises à jour disponibles (les sorties de update_function plus récentes) seront effectuées? Existe-t-il un moyen de (db) mettre à jour exactement un module?

7 drush updating

— non-benz
source

Je sais que cette question est assez ancienne, mais je suis curieux: pourquoi voudriez-vous cela? Normalement, tout le code est basé sur l'hypothèse que la base de données est à jour. Si vous ne souhaitez pas que la mise à jour db d'un module spécifique s'exécute, ne devez-vous pas rétablir le module entier dans une version antérieure?

— marcvangend

1

un an plus tard. J'en avais besoin pour les éléments suivants: j'ai créé un module personnalisé, mais j'ai changé la disposition de la table plus tard (toujours au stade du développement), donc cela aurait été pratique de simplement mettre à jour la base de données avec le nouveau schéma.

— Maarten Hartman

10

Non, tu ne peux pas.

Si vous souhaitez mettre à jour chaque module individuellement, mettez à jour uniquement les fichiers d'un seul module, puis exécutez updatedb.

— Berdir
source

Voir le commentaire ci-dessous sur l'utilisation drush dl(vous voulez probablement supprimer l'ancien module en premier afin de ne pas conserver les anciens fichiers non destinés à la nouvelle version!)

— doublejosh

Existe-t-il un moyen de le faire en dehors de la drush?

— lathomas64

2

@ahimsauzi a donné la bonne réponse

— cybercampbell

21

Sur Drush 5.7, vous pouvez exécuter la commande drush pm-update --no-core module-name. Drush sauvegarde automatiquement le module actuel, télécharge la nouvelle version et vous invite à mettre à jour la base de données.

— ahimsauzi
source

6

Cela exécutera TOUTES les mises à jour en attente, pas seulement celles du module que vous avez mis à jour.

— moshe weitzman

Moshe, peut clarifier? J'ai exécuté la commande ci-dessus et bien que Drush vérifie TOUTES les mises à jour en attente, seul le module spécifié (nom du module ci-dessus) sera mis à jour. Suis-je en train de manquer quelque chose?

— ahimsauzi

6

Il vérifie toutes les mises à jour de code en attente et ne met à jour que le code du module spécifié, mais il traite toutes les mises à jour de la base de données .

— meustrus

8

Si vous souhaitez exécuter une seule mise à jour, vous pouvez l'exécuter drush eval foo_update_33(), par exemple. En pratique, c'est un peu plus complexe que cela car il faut charger le fichier .install mais pas beaucoup.

Vous pouvez également essayer la solution @macaleaa:

drush php-eval 'module_load_install('my_module');my_module_update_7XXX();'

— moshe weitzman
source

3

J'ajouterai que ce serait génial si quelqu'un faisait une extension Contrib pour Drush qui vous permettait d'exécuter les mises à jour sélectionnées. Ce n'est pas une chose sûre à faire en général, mais parfois tu dois vivre dangereusement. Cependant, cela ne convient pas pour Core Drush (je suis le responsable de Drush)

— moshe weitzman

2

Pourquoi ne pas convenir au core drush? N'est-il pas possible que quelqu'un veuille appliquer un ordre particulier de mises à jour de base de données (pour le code déjà téléchargé), auquel cas chaque module individuel devrait être mis à jour séparément? Je suis moi-même dans une telle situation.

— meustrus

d'où vient le 33 d'ici? foo est-il le nom de la machine du module?

— lathomas64

Le 33 fait partie du nom de la fonction de mise à jour et détermine la commande. Et oui, foo est le nom de la machine du module. Vous pouvez trouver les fonctions dans foo.install. Par exemple, le module devel (dans devel.install) a plusieurs fonctions de mise à jour: function devel_update_7000est celle avec le nombre le plus bas, et sera exécutée en premier, puis function devel_update_7001, etc.

— Ursula

3

Voici un exemple qui charge d'abord le fichier d'installation:drush php-eval 'module_load_install('file_entity');file_entity_update_7211();'

— mcaleaa

5

ni drush up someproject, ni drush upc someprojectsemblent ne mettre à jour que le someprojectmodule. Une manière différente de ce que vous voulez est:

drush dl someproject #use --select option to be prompted for a module version
                     #this will overwrite your exising module's files
                     #backup your modules files with --backup, yourself, use a VCS to revert
drush updb           #run available database update scripts

Voici une discussion sur un sujet similaire sur Drupal.org. Prends soin !

— moi-même
source

Je viens d'essayer et drush up someprojectFONCTIONNE, MAIS malheureusement, il vérifie TOUTES les mises à jour disponibles pour les modules activés par défaut également (ce qui ne serait pas nécessaire), écrit "Update available" pour certains d'entre eux, mais met à jour UNIQUEMENT le projet spécifique. Voici une capture d'écran: i.imgur.com/TDDmB.png . Comme vous pouvez le voir, plusieurs mises à jour sont disponibles, mais seul xmlsitemap est mis à jour à l'aide drush up xmlsitemap.

— Sk8erPeter

4

J'utilise Drush 5.9, et je peux mettre à jour un seul module avec succès avec cette commande:

drush dl *project*

Ainsi, par exemple, pour mettre à jour le module 'devel':

drush up devel

— Barre
source

1

Je pense que c'est désormais possible avec Drush, en utilisant up:

drush up module_name

— zgreen
source

0

J'ai eu une situation dans laquelle une table créée par une fonction de mise à jour ( MYMODULE_update_7101), mais cette table était consultée dans le code quelque part dans chaque cache clair et presque chaque appel drush (il obtenait essentiellement les noms des types d'entité pour tous les menus et autres) autre). Courir drush updatedbcourait MYMODULE_update_7101troisième au lieu de premier.

J'ai essayé la solution suggérée par @macaleaa et @moshe weitzman de courir:

drush php-eval 'module_load_install('MYMODULE');MYMODULE_update_7101();'

avant de courir drush updatedb, mais cela n'a pas aidé - le run de drush a échoué car a updatedbessayé à nouveau de s'exécuter MYMODULE_update_7101()et s'est trompé, disant que la table existait déjà. Fondamentalement, le code ci-dessus avait exécuté la mise à jour, mais n'avait pas laissé sa marque sur le système que la mise à jour avait été exécutée. Vraisemblablement, il y a tout un tas d'autres choses update.phpà faire après avoir exécuté chaque mise à jour pour stocker le dernier numéro de version du module dans la base de données, etc.

Je suis allé update.phpvoir comment il exécute réellement chaque fonction de mise à jour et ce qu'il fait après, en recherchant une fonction à appeler qui appellerait la fonction de mise à jour et ferait toutes les autres choses. J'ai fini par y arriver:

include_once DRUPAL_ROOT . "/includes/update.inc";
$c["results"]["#abort"] = array();
update_do_one("MYMODULE", 7101, array(), $c);

Ce que j'ai couru avec drush:

drush eval 'include_once DRUPAL_ROOT . "/includes/update.inc"; $c["results"]["#abort"] = array(); update_do_one("MYMODULE", 7101, array(), $c);'

Il a exécuté la mise à jour, pas de problème, mais la version 7101 de MYMODULE est toujours apparue dans la liste des mises à jour lorsque j'ai exécuté updatedb, bien que cela se soit déroulé sans erreur et tout semblait bien lors de l'inspection du site.

Un peu hacky et 6 ans de retard, mais tout va bien qui se termine bien?

— nerdlinger
source