Bienvenue, Invité
Nom d'utilisateur : Mot de passe : Se souvenir de moi

SUJET : Abstration base de données MySQL/PostgreSQL

Abstration base de données MySQL/PostgreSQL il y a 2 ans 2 mois #85195

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
Bonjour à tous,

Etant un grand fan de PostgreSQL, j'aimerais faire une revue du support PostgreSQL et de la manière dont les requêtes SQL sont réécrites à la volée dans le core de Dolibarr. J'ai cherché dans le dossier "core" ou "includes" de Dolibarr, mais sans succès. Où le code gérant les requêtes SQL se situe-t-il ?

Merci d'avance.
L'administrateur a désactivé l'accès en écriture pour le public.

Abstration base de données MySQL/PostgreSQL il y a 2 ans 2 mois #85200

  • defrance
  • Portrait de defrance
  • Hors ligne
  • Gold Boarder
  • Dev-Leader des patas-monkey
  • Messages : 3376
  • Remerciements reçus 668
  • Karma: 131
il ne me semble pas qu'il y ait de réecritures de requete (à la volée ou au filet), elle sont compatibles avec les deux base (postgres et mariadb) dés le départ
Travis (l'outils d'intégration continue associé au dépot git de dolibarr) testant à la fois avec mariaDb et postgreSQL cela permet de garantir la pleine compatibilité entre les deux bases.
Rien ne t'empeche si tu veux améliorer les choses c'est ajouter des tests dans travis
L'administrateur a désactivé l'accès en écriture pour le public.

Abstration base de données MySQL/PostgreSQL il y a 2 ans 2 mois #85240

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
Les requêtes SQL doivent être compatibles.

Je m'interroge sur la compatibilité des requêtes d'upgrade:
github.com/Dolibarr/dolibarr/blob/develo...tion/5.0.0-6.0.0.sql

La syntaxe MySQL:
dev.mysql.com/doc/refman/5.7/en/alter-table.html

Il y a de nombreuses différences avec la syntaxe SQL99 standard:
www.postgresql.org/docs/devel/static/sql-altertable.html

Par exemple, ces requêtes vont aboutir à une erreur sous PostgreSQL:
MySQL: To rename a column: ALTER TABLE llx_table CHANGE COLUMN oldname newname varchar(60);
Il fallait écrire :
PostgreSQL: ALTER TABLE llx_table ALTER COLUMN oldname RENAME newname;

MYSQL : To change type of field: ALTER TABLE llx_table MODIFY COLUMN name varchar(60);
Il fallait écrire :
ALTER TABLE llx_table ALTER COLUMN type varchar(60);
L'administrateur a désactivé l'accès en écriture pour le public.

Abstration base de données MySQL/PostgreSQL il y a 2 ans 2 mois #85241

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
MariaBD est bien compatible SQL99 ;)
mariadb.com/kb/en/sql-99/alter-table-statement/

Par exemple :
ALTER TABLE <Table name> <alter table action>

<alter table action> ::=
ADD [ COLUMN ] <Column definition> |
ALTER [ COLUMN ] <Column name> SET DEFAULT default value |
ALTER [ COLUMN ] <Column name> DROP DEFAULT |
ALTER [ COLUMN ] <Column name> ADD SCOPE <Table name list> |
ALTER [ COLUMN ] <Column name> DROP SCOPE {RESTRICT | CASCADE} |
DROP [ COLUMN ] <Column name> {RESTRICT | CASCADE} |
ADD <Table Constraint> |
DROP CONSTRAINT <Constraint name> {RESTRICT | CASCADE}

<Table name list> ::=
(<Table name> [ {,<Table name>}... ]) |
<Table name>

Donc il faut réécrire le code de migration SQL pour qu'il prennen en compte le standard SQL99.
Je pense que MySQL doit comprendre le SQL99, car c'est dans ses SPECs.
Par contre, comme toujours les éditeurs de MySQL ont implanté une syntaxe "bis", destinée à emprisonner les utilisateurs dans une syntaxe non-standard.

Bon, je vais devoir installer MySQL pour vérifier qu'il supporte SQL99, ensuite je réécrirai les requêtes.
C'est assez technique et cela nécessite la maîtrise de SQL99, je m'en charge.

Par contre, il faudra que MySQL fonctionne en mode ANSI. :woohoo:
Je pense que c'est toujours le cas chez les hébergeurs.
Mais c'est nécessaire si l'on veut supporter toute base de données.
Dernière édition: il y a 2 ans 2 mois par fperou.
L'administrateur a désactivé l'accès en écriture pour le public.

Abstration base de données MySQL/PostgreSQL il y a 2 ans 2 mois #85242

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
L'administrateur a désactivé l'accès en écriture pour le public.

Abstration base de données MySQL/PostgreSQL il y a 2 ans 2 mois #85244

  • defrance
  • Portrait de defrance
  • Hors ligne
  • Gold Boarder
  • Dev-Leader des patas-monkey
  • Messages : 3376
  • Remerciements reçus 668
  • Karma: 131
tu as regardé le paramétrage de Travis?
Il me semble que le controle sur les normes SQL sont en place justement
Les montés de versions fonctionnent depuis pas mal de temps, y compris au niveau de postgre donc j'ai tendance à penser qu'il n'y a pas de choses à faire de ce coté...
tu as regardé ici?
github.com/Dolibarr/dolibarr/tree/develo...tall/pgsql/functions
L'administrateur a désactivé l'accès en écriture pour le public.

Abstration base de données MySQL/PostgreSQL il y a 2 ans 2 mois #85269

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
Il y a bien une couche d'abstraction dans htdocs/core/db
Database.interface.php DoliDB.class.php index.html mssql.class.php mysqli.class.php pgsql.class.php sqlite3.class.php

Les requêtes sont réécrites à la volée et c'est même bien écrit. Par exemple ALTER TABLE CHANGE COLUMN donne bien deux requêtes sous PostgreSQL selon qu'on change le type ou que l'on renomme la colonne d'une table.
Dernière édition: il y a 2 ans 2 mois par fperou.
L'administrateur a désactivé l'accès en écriture pour le public.