Migrations de bases de données en Kotlin : Aperçu des outils et approches

Migrations de bases de données en Kotlin : Guide complet des outils et approches

La gestion des modifications du schéma de base de données est l'une des tâches clés lors du développement de toute application. Dans l'écosystème Kotlin, il existe plusieurs solutions matures qui permettent d'automatiser ce processus. Dans cet article, nous allons analyser trois approches principales : les outils intégrés de l'ORM Exposed, le classique Flyway et le puissant Liquibase. Vous apprendrez à les intégrer dans un projet Kotlin et quel outil choisir pour des tâches spécifiques.

1. Pourquoi les migrations sont-elles nécessaires ?

L'exécution manuelle de scripts SQL sur différents environnements (environnement de développement local, staging, production) conduit inévitablement à une désynchronisation du schéma. Les migrations résolvent ce problème en offrant :

• Le versionnage des modifications de la base de données
• L'application automatique des nouveaux scripts au démarrage de l'application
• La possibilité de revenir en arrière (rollback) à une version précédente
• Le travail en équipe sans conflits de schéma

2. Exposed : Support natif des migrations

Exposed est un ORM léger de JetBrains, écrit en Kotlin. Depuis la version 0.41.0, la bibliothèque fournit son propre mécanisme de migration qui s'intègre parfaitement dans l'écosystème Kotlin.

Installation

// build.gradle.ktsimplementation("org.jetbrains.exposed:exposed-core:0.55.0")implementation("org.jetbrains.exposed:exposed-dao:0.55.0")implementation("org.jetbrains.exposed:exposed-migrations:0.55.0")

Création d'une migration

Chaque migration est une classe héritant de VoidDatabaseMigration :

import org.jetbrains.exposed.sql.transactions.transactionimport org.jetbrains.exposed.sql.SchemaUtilsimport org.jetbrains.exposed.sql.Tableimport org.jetbrains.exposed.migrations.VoidDatabaseMigration

object Users : Table() {    val id = integer("id").autoIncrement()    val name = varchar("name", 255)    override val primaryKey = PrimaryKey(id)}

class V1__CreateUsersTable : VoidDatabaseMigration() {    override fun migrate() {        transaction {            SchemaUtils.create(Users)        }    }}

class V2__AddEmailColumn : VoidDatabaseMigration() {    override fun migrate() {        transaction {            SchemaUtils.addColumn(Users, Users.varchar("email", 255))        }    }}

Exécution des migrations

import org.jetbrains.exposed.migrations.ExposedMigrationUtilsimport javax.sql.DataSource

fun runMigrations(dataSource: DataSource) {    ExposedMigrationUtils.runMigrations(        dataSource = dataSource,        migrationsPackage = "com.example.migrations"    )}

Avantages : entièrement en style Kotlin, pas de fichiers SQL, noms de colonnes typés.
Inconvénients : dépendance à Exposed, pas de suivi visuel, absence de rollback "prêt à l'emploi".

3. Flyway : Simplicité et fiabilité

Flyway est l'outil de migration le plus populaire dans le monde JVM. Il fonctionne avec n'importe quelle base de données et ne dépend pas d'un ORM. En Kotlin, on l'utilise via le SDK officiel ou le plugin Gradle.

Connexion

// build.gradle.ktsimplementation("org.flywaydb:flyway-core:10.20.0")// Pour PostgreSQL, ajoutez le driver :implementation("org.postgresql:postgresql:42.7.4")

Structure des migrations

Flyway utilise des fichiers SQL avec une nomenclature spécifique :

db/migration/   V1__create_users.sql   V2__add_email_column.sql   V3__add_role_column.sql

Exemple de migration SQL (V1__create_users.sql)

CREATE TABLE users (    id SERIAL PRIMARY KEY,    name VARCHAR(255) NOT NULL,    email VARCHAR(255) UNIQUE);

Intégration avec Kotlin

import org.flywaydb.core.Flywayimport javax.sql.DataSou