DEV Community: Guillaume Benoot

Migration Oracle -> PostgreSQL : il n’y a que le driver à changer ! Non ?

Guillaume Benoot — Wed, 07 May 2025 14:29:08 +0000

Migration Oracle -> PostgreSQL : il n’y a que le driver à changer ! Non ?

Cet article n’a pas vocation à encenser PostgreSQL ni à dénigrer Oracle. Il s’agit de vous présenter les problèmes que nous avons rencontrés, comment nous les avons résolus et, pour certains, comment nous aurions pu les anticiper.

Notre client a décidé de migrer ses bases de données Oracle vers PostgreSQL et nous a sollicités pour réaliser cette migration.
Sur le papier, cela semble simple : il suffit de changer le driver Oracle par le driver PostgreSQL et le tour est joué.
Mais le plan ne s'est pas déroulé sans accrocs.

Un peu d’histoire :

Pour comprendre une partie des problèmes rencontrés, il faut revenir sur l’histoire de SQL :

1970 : IBM créé SEQUEL, un langage permettant d’interroger et éditer une base de données relationnelles, il sera renommé par la suite SQL en 1975.
1979 : Relational Software Inc (devenue Oracle Corporation) s’inspire des travaux d’IBM et présente la première version commerciale du SGBD.
1986 : toutes les plus grandes entreprises du secteur se réunissent pour établir la première norme SQL. Elles sont toutes présentes sauf Oracle.
1995 : la troisième révision de la norme SQL voit le jour. PostgreSQL est créé : ils implémentent la norme.

On remarque qu’Oracle a suivi son propre chemin vis-à-vis de la norme SQL alors que PostgreSQL en bon élève a mis en œuvre tout ou partie de cette norme.

Après des années d'évolution de la norme, PostgreSQL demeure parmi les plus conformes. Oracle rattrape son retard petit à petit et se rapproche de plus en plus de la norme. Néanmoins, le mal est fait. Durant des années, les fonctionnalités propres à Oracle ont été disséminées dans de trop nombreux projets. C’est pourquoi il est nécessaire de migrer ces fonctionnalités vers celles équivalentes en PostgreSQL.

Migration de la base de données :

Quand on évoque la migration d’une base de données, il faut penser à tout ce qui la structure : tables, séquences, vues, vues matérialisées, procédures stockées, triggers, fonctions, grants, dblink, types etc …

Tout cela sans compter les données ! Heureusement, cela ne se fait pas manuellement, il existe plusieurs logiciels sur le marché capables d’effectuer cette tâche.

Nous allons vous présenter celui qui a été utilisé sur notre projet : ora2pg.

Cet utilitaire a été créé en 2001, il est open source et est toujours maintenu par la communauté. Il fait partie des leaders du marché.

L’utilisation la plus simple de cet utilitaire s’effectue en quelques étapes :

Exécution des scripts d’export de la structure de la base de données Oracle ainsi que des données au format SQL.
Conversion vers un format SQL compatible PostgreSQL.
Exécution des scripts d’import dans la base de données PostgreSQL.

ora2pg est également capable de convertir du PL/SQL en PL/pgSQL. Il propose beaucoup plus de fonctionnalités. Il permet notamment de choisir les objets que nous souhaitons migrer, convertir certains types vers d’autres ou encore, d’estimer le coût en jour-homme et la complexité de tout ce qui n’a pas pu être migré de manière automatique. La documentation est bien écrite et complète.

La théorie ayant été énoncée, place au concret et à l’analyse de l’application à migrer.

Étude du patrimoine applicatif :

Lorsqu’un ORM (Object-Relational Mapping) tel que Spring Data JPA ou Hibernate est utilisé dans les composants, cela apporte une couche d’abstraction vis-à-vis de l’utilisation de la base de données. Bien évidemment, cette abstraction facilite grandement la migration d’un SGBD vers un autre.

Malheureusement, ce n’est pas le cas sur les projets que nous avons dû migrer. Les accès à la base de données sont réalisés via des requêtes SQL natives. Les composants sont développés en Java, il s’agit d’une IHM et de quelques batchs.

La particularité de l’IHM est qu’elle intègre des dépendances d’applications tierces utilisant d’autres bases de données Oracle ne faisant pas partie du projet de migration à court terme. La stratégie de notre client est de ne plus utiliser ces dépendances au profit d’appels HTTP à des API tierces. Nous avons pu retrouver toutes les fonctionnalités qu’offraient ces dépendances via les ressources exposées par les API tierces.

Le périmètre de la migration semble plutôt simple :

Migrer la base de données Oracle en PostgreSQL
Remplacer le driver Oracle par le driver PostgreSQL dans chaque composant
Remplacer les dépendances tierces par des appels HTTP à des API tierces
Adapter les requêtes SQL utilisant des fonctions spécifiques à Oracle

Début des travaux :

Une fois la base de données migrées en utilisant ora2pg décrit précédemment, nous sommes passés sur l’adaptation des requêtes SQL.

Il existe plus d’une centaine de fonctions dans Oracle et PostgreSQL. Celles qui respectent la norme sont équivalentes. Nous allons passer en revue les fonctions couramment utilisées et spécifiques à Oracle et leur équivalence PostgreSQL.

Fonctionnalité Oracle	Équivalent PostgreSQL
Table DUAL	On peut créer une vue se nommant DUAL dans PostgreSQL pour faciliter la migration.
`CREATE SEQUENCE`	fonctionne aussi. Utilisation avec `nextval('seq')`.
Préfixe des colonnes lors d’un UPDATE `UPDATE t SET t.col = ...`	même syntaxe supportée mais pas nécessaire.
Sous-requête `SELECT * FROM (SELECT * FROM ma_table) MON_ALIAS;` ok	`SELECT * FROM (SELECT * FROM ma_table) AS MON_ALIAS;`
`MINUS`	`EXCEPT`.
DECODE	`CASE WHEN ... THEN ... ELSE ... END`.
NVL	`COALESCE(val, remplacement)`.
Opérateur (+)	`LEFT JOIN`, `RIGHT JOIN`, `FULL OUTER JOIN`.
Chaînes vides `''` est traité comme `NULL`	`''` ≠ `NULL`

Le traitement des dates est un vaste sujet. Voici quelques exemples :

Fonctionnalité Oracle	Équivalent PostgreSQL
`DATE` = date et heure	`DATE` = date uniquement
`CURRENT` = fuseau horaire de la session	`CURRENT` = fuseau horaire de l’OS
`date1 - date2` (en jours)	Retourne un `interval`.

Il s’agit là que d’un échantillon mais comme vous pouvez le voir, cela peut être long et fastidieux de tout adapter. Sachez qu’il existe une extension nommée orafce permettant d’émuler une partie des fonctions et packages d’Oracle au sein de PostgreSQL. Cette extension prend la forme d’un fichier SQL à exécuter avec les bons droits sur le serveur PostgreSQL.

Cette extension est supportée par AWS Aurora et Azure Database depuis respectivement 2018 et 2019. Voici quelques extraits du fichier d’installation :

-- emulation of dual table
CREATE VIEW oracle.dual AS SELECT 'X'::varchar AS dummy;
REVOKE ALL ON oracle.dual FROM PUBLIC;
GRANT SELECT, REFERENCES ON oracle.dual TO PUBLIC;

CREATE OR REPLACE FUNCTION oracle.nvl(int, int)
RETURNS int AS $$
SELECT coalesce($1, $2)
$$ LANGUAGE sql IMMUTABLE;

L’installation de cette extension peut faciliter l’adaptation des requêtes SQL si votre projet est contraint par le temps ou le coût.
Néanmoins, votre projet continuera d’utiliser des spécificités d’Oracle ne faisant pas partie de la norme SQL.
Charge à vous de poursuivre ou non la migration au fil de l’eau par la suite.

Une fois la base de données migrée, les drivers changés, et requêtes adaptées, nous débutons la campagne de tests de non-régression sur l’application.

Premiers tests post-migration :

Très rapidement une erreur est remontée par l’un des composants :

org.postgresql.util.PSQLException: ERROR: relation "articles” does not exist

La table “ARTICLES” n’existe pas … Nous nous rendons compte que notre application utilise une autre base de données. Pour comprendre pourquoi nous ne l’avons pas vu, il est nécessaire de vous expliquer comment est structurée une base de données.

Dépendances Oracle tierces :

Un serveur de base de données contient une ou plusieurs instances. Chaque instance contient un ou plusieurs schémas. Chaque schéma contient une ou plusieurs tables.
Dans Oracle, il est possible d’autoriser un schéma à accéder à une table d’un autre schéma en lecture ou modification. Cela s’effectue via des GRANT. Il est également possible d’autoriser un schéma à accéder à un autre schéma d’une autre instance (voir d’une autre base de données) via le mécanisme de DBLINK.
A l’utilisation, cela revient à exécuter les requêtes SQL suivantes :

SELECT FROM SCHEMA_DIST.ARTICLES      -- grant
SELECT FROM ARTICLES@SCHEMA_DIST      -- dblink

L’écriture de ces requêtes n’est pas commune, nous aurions dû nous en rendre compte. Mais c’est sans compter l’utilisation de SYNONYM !
Les SYNONYM permettent de créer une sorte d’alias pour faciliter l’écriture de requête. Concernant les GRANT et DBLINK, il est possible de déclarer un SYNONYM de cette manière :

CREATE SYNONYM ARTICLES  FOR SCHEMA_DIST.ARTICLES
CREATE SYNONYM ARTICLES2 FOR ARTICLES@SCHEMA_DIST

Ce qui donne à l’utilisation :

SELECT FROM ARTICLES
SELECT FROM ARTICLES2

L’utilisation des GRANT et DBLINK est donc tout simplement cachée. Si l’application est mal ou peu documentée, on perd la visibilité sur ce couplage fort entre deux schémas distincts.
Il est nécessaire de bien identifier les dépendances lors de l’étude initiale. Les trois requêtes suivantes permettent respectivement de retrouver les GRANT, DBLINK et SYNONYM déclarés dans votre schéma.

SELECT GRANTOR, TABLE_NAME, TABLE_SCHEMA
FROM ALL_TAB_PRIVS WHERE GRANTEE IN ('MON_USER', 'PUBLIC');
SELECT DB_LINK, HOST
FROM ALL_DB_LINKS;
SELECT SYNONYM_NAME, TABLE_OWNER, TABLE_NAME, DB_LINK
FROM ALL_SYNONYMS WHERE OWNER IN ('MON_USER', 'PUBLIC');

Poursuite des tests :

Une fois ces dépendances remplacées par des appels HTTP à des API tierces, nous avons repris les tests de non-régression sur l’ensemble de l’application.
Nous avons été confrontés à une dernière anomalie : il s’agissait d’un bug présent dans le driver PostgreSQL. N’hésitez pas à aller consulter le bug tracker de PostgreSQL si vous faites face à des comportements étranges ou insolubles à l’exécution de vos tests : https://github.com/pgjdbc/pgjdbc/issues

Conclusion :

Pour conclure, nous aimerions rappeler qu’il faut bien s’outiller pour effectuer une migration Oracle vers PostgreSQL. ora2pg semble indispensable pour la phase initiale concernant la structure et les données. N’hésitez pas à utiliser les types de données natifs dans PostgreSQL. L’installation d’extension telle que orafce dépendra des contraintes de votre projet.
L’étude initiale est importante, prenez le temps d’identifier toutes les dépendances externes à votre application. Notamment en exécutant les trois requêtes fournies précédemment qui vous permettront d’éviter les surprises.
La phase de test de non-régression est nécessaire pour déceler les derniers problèmes que pourrait engendrer une migration de ce type. Consultez le bug tracker du driver si cela est nécessaire.
Enfin, sachez qu’il n’existe pas d’outil miracle permettant de faire une migration de manière complètement automatisée. Des ajustements manuels seront nécessaires. Nous espèrons avoir levé le voile sur ce qu’était une migration et vous éviter de tomber dans les mêmes pièges que nous avons rencontrés.

Références

La vie d'une JEP n'est pas un long fleuve tranquille

Guillaume Benoot — Tue, 29 Apr 2025 14:32:31 +0000

Tous les 6 mois, une nouvelle version de JAVA sort.
Le JDK est mis à jour, de nouvelles fonctionnalités sont ajoutées et parfois certaines sont retirées.
Le JDK c'est le JAVA developpement kit, il contient des outils et des bibliothèques qui permettent d'écrire des applications en JAVA.

Avec chaque mise à jour du JDK on entend parler des JEP qu'elle intègre.
Mais c'est quoi exactement une JEP ?

JEP ou JDK Enhancement Proposal

Une JEP c'est un document texte qui va permettre de définir une nouvelle fonctionnalité.

C'est un document vivant qui va évoluer au cours de sa vie.
Des sections vont être ajoutées, modifiées ou supprimées.

Une JEP doit être rédigée:

pour toutes modifications significatives du JDK
si une modification demande plus de 2 semaines de travail
ou si cette modification vient suite à une grande demande des développeurs

Toutefois, il y à beaucoup de modifications qui ne remplissent pas ces conditions et qui sont tout de même intégrées au JDK. On pourra trouver la liste de ces modifications dans la release note qui accompagne la sortie de la nouvelle version du JDK.

Pour proposer une JEP, on va la créer à partir d'un template, puis la soumettre par mail à OpenJDK.

C'est a partir de ce document que l'on va pouvoir commencer à discuter de cette modification dans la communauté OpenJDK et que le travail va pouvoir commencer.

OpenJDK

La communauté OpenJDK, c'est une association de développeurs qui collaborent autour de l'implémentation open source de la plateforme JAVA Standard Edition (JAVA SE).

Elle a été créée en 2006 quand une partie du code source de JAVA a été publié sous license GPLv2.

La communauté est composée de développeurs avec différents statuts.

Qui est qui chez OpenJDK ?

En souscrivant à une mailing list d'OpenJDK, on obtient le rôle de Participant.
C'est le tout premier rôle qui va permettre de participer aux discussions de ces mailing list.

Pour pouvoir passer aux choses sérieuses et commencer à écrire du code qui va changer (ou pas) la face de JAVA, il va falloir signer l'Oracle Contributor Agreement (OCA).
C'est un document juridique qui va donner les droits de ton code à Oracle.
À partir de ce moment, on devient Contributor et les choses sérieuses commencent.
Dorénavant on peut soumettre des modifications du code, proposer de nouveaux projets et assumer divers rôles au sein de groupes ou de projets.

Au fil de des contributions, on va être amené à échanger avec d'autres développeurs, et notamment des OpenJDK Members. Et une fois que l'on aura participé à plusieurs modifications significatives, notre nom pourra être proposé afin de devenir OpenJDK Member (après un vote des OpenJDK Members).
On aura la possibilité proposer la création de nouveaux groupes, devenir leader de groupe et participer à tout un tas de votes réservés aux OpenJDK Members. (nouveaux projets, nouveaux membres, membres extraordinaires du conseil d'administration...)

Le dernier rôle c'est celui d'OpenJDK Lead, mais là, il faudra être nommé par Oracle pour le devenir.
Il dirige les principaux efforts de la communauté, à savoir les nouvelles releases du JDK et il siège au conseil d'administration.

Les groupes

Tout ce petit monde va se réunir dans des groupes en fonction des appétences de chacun. (ex: Compiler, Security, Web...)

Un groupe peut avoir pour intérêt la création, l'amélioration ou la maintenance d'une partie spécifique de code ou bien des sujets annexes comme la documentation par exemple.

Un groupe peut devenir sponsor d'un projet. Cela veut dire qu'il estime qu'un projet est intéressant et que des membres du groupe pourront travailler sur ce projet.

Le groupe sera constitué de membres et d'un leader.
Le leader a toute autorité pour choisir de sponsoriser un projet, il sera le contact pour communiquer avec le groupe et il devra écrire un rapport sur les activités du groupe une fois par trimestre.

Les projets

Un projet est un effort collaboratif qui a pour but de produire du code, de la documentation, ou tout autre type de matériel en lien avec le projet.
Un projet peut contenir une ou plusieurs fonctionnalités, ou même l'entièreté du JDK.

Tout contributeur peut proposer la création d'un projet.
S'il est supporté par au moins un Group Lead, dont le groupe sera sponsor du projet et approuvé par les OpenJDK Members, alors le projet sera créé.

Un projet peut être sponsorisé par plusieurs groupes, mais si un projet n'a plus de sponsor, alors il est dissous et le matériel d'un projet est archivé car un projet dissous peut être recréé.

On va y trouver là aussi différents rôles.

un Author est un contributeur qui a reçu les droits pour créer des changements dans le code, mais il n'a pas les droits pour pousser directement sur le dépôt GIT.
un committer est un auteur qui a le droit de "pousser" sur le depôt.
Il peut nommer de nouveaux committers.
un reviewer est une committer expérimenté qui a l'autorité d'approuver les changements dans le code. Il peut nommer ou révoquer un autre reviewer.
un Project lead est un committer qui a la responsabilité de diriger et coordonner les activités de ce projet.
Il a toute autorité sur la partie technique du projet.
Il peut ajouter ou retirer des auteurs qui ne sont pas committers sur le projet.
Il peut demander des modifications de code dans un repository.
Il a l'obligation d'être le point d'entrée du projet pour les mailing lists, le contenu web et les repositories.
Il doit publier une fois par trimestre un rapport sur les activités du projet.
Il est considéré comme reviewer.
Il est nommé par les group leads qui sponsorisent le projet.
Lors de la création du projet, c'est lui qui nomme les auteurs, committers et reviewers.

Le Governing Board

C'est un groupe qui manage la structure et les opérations de la communauté OpenJDK.
Il est composé de 5 contributeurs:

Le Président, nommé par Oracle.
Le Vice Président, nommé par IBM.
L'OpenJDK Lead nommé par Oracle.
2 membres extraordinaires, qui sont nommés suite à un vote des OpenJDK Members pour une durée de 1 an à compter du 1er Avril de chaque année.

Il gère la structure et les opérations de la communauté via règlement qu'il maintient et fait respecter.
Il peut trancher des litiges procéduraux.
Il n'a pas d'autorité directe sur des décisions techniques.

Le cycle de vie d'un JEP

Maintenant que nous connaissons mieux OpenJDK et surtout le rôle de chacun, il va être très facile de comprendre le schéma ci dessous fournis par OpenJDK.
En noir nous aurons les différents états de la JEP et en vert, qui modifie cet état.

La JEP va donc passer par différents états et c'est la personne en vert sur le schéma qui la fera passer d'un état à un autre.

Draft - c'est le 1er état de la JEP, le template correctement rempli a été fourni à OpenJDK et un numéro JBS lui a été attribué*. On va pouvoir commencer à la diffuser dans la communauté afin de valider que l'idée est bonne et réalisable.
Submitted - La JEP est soumise pour être évaluée par toute la communauté afin d'être ajoutée à la roadmap.
Candidate - La JEP a été ajoutée à la roadmap. C'est à ce moment qu'elle reçoit un numéro officiel. Le propriétaire de la JEP va commencer à établir un plan d'ingénierie.
Proposed to target - Une fois qu'un plan d'ingénierie crédible est établi, une release du JDK est ciblée pour la livraison.
Targeted - le plan d'ingénierie a été validé par les committers et reviewers du projet.
Integrated - le développement et les tests unitaires sont faits.
Complete - les tests fonctionnels, de performance et de conformité sont livrés.

Rejected - Une JEP peut être rejetée si l'openJDK Lead estime qu'elle est trop complexe à mettre en oeuvre.
Withdrawn - Une JEP peut aussi être retirée par son propriétaire s'il estime qu'elle a besoin d'être retravaillée par exemple.

Il existe des JEP de procédures (elles décrivent le fonctionnement d'openJDK) et d'infrastructure (elles décrivent les systèmes et outils utilisés pour développer et maintenir le JDK).
Ces JEP ont un numéro inférieur à 100 et elles n'ont évidemment pas d'étape de développement et elles passent directement du statut Candidate à Delivered.

Envie de te lancer ?

La première chose à faire, c'est de souscrire aux mailing lists des sujets qui t’intéressent.
Ensuite, la contribution à OpenJDK peut prendre plusieurs formes.
De l'écriture de code pour de nouvelles fonctionnalités ou de patchs bien sûr, mais pas que.

La participation aux discussions dans les mailing lists (propositions fonctionnelles, participation aux choix techniques...), le test des nouvelles features, et le feedback qui va avec, le retour sur des bugs que tu as pu constater ou que d'autres ont constaté (sur des forums par exemple) accompagné d'un travail de recherche pour les rendre reproductibles sont très appréciés et sont aussi considérés comme des contributions.

Si tu veux écrire du code, signe l'OCA ou vois si ton entreprise l'a déjà signée.
Avant de proposer un changement dans le code, il est important d'échanger avec les membres de la communauté afin d'en valider l'utilité et les choix techniques de ce changement par exemple.
Cela permettra par la même occasion de trouver un contributeur qui acceptera de devenir ton sponsor et de t'accompagner dans toutes les tâches administratives (mise à jour des JBS*, revue de code, tests additionnels...)

Enfin, même si tu choisis de ne pas participer, s'intéresser aux JDK Enhancement Proposals te permet de rester informé des futures nouveautés de JAVA et de mieux appréhender celles qui viennent d'être livrées dans le dernier JDK. De plus, les discussions sur les mailing lists peuvent s'avérer très enrichissantes pour approfondir ta compréhension du fonctionnement du JDK.

*JBS pour JDK Bug System, un outil Jira qui permet de suivre les problèmes remontés pour chaque JEP.