Nous utilisons le plugin Flyway Gradle pour effectuer nos migrations hors ligne (c’est-à-dire que nous migrons lorsque le système est en panne). Nous avons récemment migré vers Flyway 5.0.7 et nous voyons maintenant cet avertissement pour les migrations:
Impossible de trouver la table d'historique de schéma XXXXXXX
.flyway_schema_history
, mais a trouvé XXXXXXX
.schema_version
à la place. Vous voyez ce message parce que Flyway a changé sa valeur par défaut pour flyway.table dans la version 5.0.0 en flyway_schema_history et que vous utilisez toujours l'ancienne valeur par défaut (schema_version). Définissez flyway.table = schema_version dans votre configuration pour résoudre ce problème. Ce mécanisme de secours sera supprimé dans Flyway 6.0.0.
(J'ai utilisé le XXXXXXX pour masquer le nom du schéma).
Donc, il semble que nous puissions éviter l'erreur en définissant flyway.table = schema_version. Mais, il indique également que ce mécanisme sera supprimé dans Flyway 6.0.0.
Sommes-nous censés faire quelque chose pour rendre cela compatible? Devons-nous renommer manuellement la table schema_version en flyway_schema_history? Ou y a-t-il un moyen de faire en sorte que Flyway le fasse? Sinon, que va-t-il se passer lorsque Flyway 6.0.0 sera disponible? Va-t-il automatiquement migrer les données vers le nom de table approprié?
La valeur par défaut pour flyway.table
est passée de schema_version
à flyway_schema_history
. Et ils ont également fourni un retour automatique à l'ancien paramètre par défaut avec un avertissement pour éviter de casser les installations existantes utilisant l'ancien paramètre par défaut.
Cela signifie qu'à partir de la voie 5, si vous ne spécifiez pas la propriété flyway.table
dans votre fichier de configuration, alors la voie cherchera la table flyway_schema_history
dans la base de données, et si elle n'est pas trouvée, elle cherchera la table schema_version
comme solution de secours et si l'ancienne table est trouvée. puis avertira avec le message que vous recevez maintenant. À partir de la voie de migration 6, ce mécanisme de secours sera supprimé. Si vous ne fournissez pas la propriété flyway.table
, il recherchera flyway_schema_history
dans la base de données. S'il n'est pas trouvé, il ne recherchera pas la table schema_version
, même si vous en avez, et créera une nouvelle table nommée flyway_schema_history
pour conserver les fonctionnalités.
Dans la voie 6, votre système existant fonctionnera correctement si vous définissez flyway.table=schema_version
, vous n'avez pas besoin de changer le nom de la table dans la base de données. Mais si vous ne définissez pas la propriété, vous devrez alors modifier le nom de la table, sinon flyway ne reconnaîtra pas la table schema_version existante, traitera le système comme un nouveau, créera une table flyway_schema_history et commencera à exécuter les scripts à partir de.
En espérant que ça va aider.
Il est possible de migrer de version_schema vers flyway_schema_history en mappant une table sur une autre et en copiant les enregistrements pertinents:
DROP TABLE IF EXISTS `flyway_schema_history`;
SET character_set_client = utf8mb4 ;
CREATE TABLE `flyway_schema_history` (
`installed_rank` int(11) NOT NULL,
`version` varchar(50) DEFAULT NULL,
`description` varchar(200) NOT NULL,
`type` varchar(20) NOT NULL,
`script` varchar(1000) NOT NULL,
`checksum` int(11) DEFAULT NULL,
`installed_by` varchar(100) NOT NULL,
`installed_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`execution_time` int(11) NOT NULL,
`success` tinyint(1) NOT NULL,
PRIMARY KEY (`installed_rank`),
KEY `flyway_schema_history_s_idx` (`success`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
insert into flyway_schema_history (installed_rank, version, description, type, script, checksum, installed_by, installed_on, execution_time, success)
select installed_rank, version, description, type, script, checksum, installed_by, installed_on, execution_time, success
from schema_version;
Ceci est la version de schéma de flyway_schema_history à partir de flyway 5.2.2. Je recommande, pour utiliser ce script en toute sécurité, de migrer auparavant vers cette version, puis d'avancer.
S'il vous plaît, comprenez que ce script doit être exécuté tel qu'il est dans votre console de base de données. Ce script est pour MySQL uniquement. Vous devez créer la vôtre pour d'autres bases de données.