r10935 - in spip/ecrire: base exec inc install req

Notifications Commit Core
1

Author: marcimat@free.fr
Date: 2007-12-10 14:41:39 +0100 (lun, 10 déc 2007)
New Revision: 10935

Log:
Intégration d'un portage SQLite, qui gère les versions 2 et 3 de ce serveur.
Origine des travaux (pour historique) : http://zone.spip.org/trac/spip-zone/browser/dev/sqlite/

Introduction d'une constante _DIR_DB qui correspond à l'emplacement des fichiers de base de données sqlite. Par défaut : _DIR_ETC/bases/ soit 'config/bases/'

Au chargement de sqlite, celui ci essaie de charger les modules php sqlite s'ils ne sont pas chargés (cas de Ouvaton notamment). L'installation propose alors le/les choix supplémentaires 'SQLite 2' et/ou 'SQLite 3', selon les versions présentes.

Quelques menus changements sont nécessaires :
- passer $serveur à sql_errno et sql_error
- éviter que menu_rubriques.php génère des IN ( , x , y , z) mais bien IN (0, x ,y ,z); Nota : je me demande si le zero est utile.
- predef_ou_cache() de install.php semble nécessiter des parenthèses supplémentaires sinon ouvaton n'est pas content (?)
- inc/auth.php : l'update sur la table auteur ne peut se faire en sqlite que s'il n'y a pas sur le même $link une ressource en lecture sur la même table. Si $res = $link->query('SELECT spip_auteurs...'); alors il faut faire unset($res); avant un $link->query('UPDATE spip_auteurs...');

Modified:
   spip/ecrire/base/abstract_sql.php
   spip/ecrire/exec/menu_rubriques.php
   spip/ecrire/inc/auth.php
   spip/ecrire/inc/install.php
   spip/ecrire/install/etape_2.php
   spip/ecrire/req/mysql.php
   spip/ecrire/req/pg.php

Details: http://trac.rezo.net/trac/spip/changeset/10935

2

Le 10 déc. 07 à 14:41, marcimat@free.fr a écrit :

Author: marcimat@free.fr
Date: 2007-12-10 14:41:39 +0100 (lun, 10 déc 2007)
New Revision: 10935

Log:
Intégration d'un portage SQLite

Bravo Mathieu. Ca me fait bien plaisir que mon travail de cet été fasse des petits. Et je suis surpris que tu aies dû changer aussi peu de choses dans abstract_sql, je m'attendais à des abstractions supplémentaires à mettre au point, tu es sûr que tout marche a priori ?

Et une question: ça t'a pris combien de temps ?

Encore bravo

  Emmanuel

3

Et pour le coup un support multibase mysql/postgre/sqlite à de l'allure
Cédric

Le 12 déc. 07 à 08:59, Committo,Ergo:sum a écrit :

Le 10 déc. 07 à 14:41, marcimat@free.fr a écrit :

Author: marcimat@free.fr
Date: 2007-12-10 14:41:39 +0100 (lun, 10 déc 2007)
New Revision: 10935

Log:
Intégration d'un portage SQLite

Bravo Mathieu. Ca me fait bien plaisir que mon travail de cet été
fasse des petits. Et je suis surpris que tu aies dû changer aussi peu
de choses dans abstract_sql, je m'attendais à des abstractions
supplémentaires à mettre au point, tu es sûr que tout marche a priori ?

Et une question: ça t'a pris combien de temps ?

Encore bravo

  Emmanuel

_______________________________________________
spip-team@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-team

4

ouais, un bon argument "marketing" pour la sortie de la W.X le Y/Z/200[7|8] :wink:

On Dec 12, 2007 9:05 AM, Cédric MORIN <cedric.morin@yterium.com> wrote:

Et pour le coup un support multibase mysql/postgre/sqlite à de l'allure
Cédric

Le 12 déc. 07 à 08:59, Committo,Ergo:sum a écrit :

>
> Le 10 déc. 07 à 14:41, marcimat@free.fr a écrit :
>
>> Author: marcimat@free.fr
>> Date: 2007-12-10 14:41:39 +0100 (lun, 10 déc 2007)
>> New Revision: 10935
>>
>> Log:
>> Intégration d'un portage SQLite
>
> Bravo Mathieu. Ca me fait bien plaisir que mon travail de cet été
> fasse des petits. Et je suis surpris que tu aies dû changer aussi peu
> de choses dans abstract_sql, je m'attendais à des abstractions
> supplémentaires à mettre au point, tu es sûr que tout marche a
> priori ?
>
> Et une question: ça t'a pris combien de temps ?
>
> Encore bravo
>
> Emmanuel
>
>
> _______________________________________________
> spip-team@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-team

_______________________________________________
spip-team@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-team

5

Committo,Ergo:sum a écrit :

Bravo Mathieu. Ca me fait bien plaisir que mon travail de cet été fasse des petits. Et je suis surpris que tu aies dû changer aussi peu de choses dans abstract_sql, je m'attendais à des abstractions supplémentaires à mettre au point, tu es sûr que tout marche a priori ?

Et une question: ça t'a pris combien de temps ?

1) ça m'a pris grosso modo 2 semaines jour et nuit (soit depuis la fin de mon précédent boulot)
Le plus long c'est de trouver les bonnes infos sur SQLite (il y en a peu) et de dénicher les petits bugs (inc/auth, j'ai mis du temps !)
En tout cas, tes abstractions sont excellente. Il reste que SPIP se base sur un nommage MySQL et qu'il faut tout traduire à partir de ce langage, ça fait beaucoup d'analyses php pour chaque requète du coup.
Mais ce n'est pas encore fini, finalement, car :

2) Non, tout ne marche pas (enfin, presque tout marche hein ^^), j'ai découvert une erreur hier sur la mise à jour des réferrers et là je n'ai pas encore eu d'idée lumineuse !
Voilà ce qu'il se passe : SQLite ne gère pas "ALTER TABLE table (DROP|ALTER) column" et il y a une requète dans /genie/popularites.php :

sql_alter("TABLE spip_referers DROP visites_veille,
        CHANGE visites_jour visites_veille INT(10) UNSIGNED NOT NULL DEFAULT '0',
        ADD visites_jour INT(10) UNSIGNED NOT NULL DEFAULT '0'");

Qui fait en plus d'un DROP, 2 autres actions en même temps (CHANGE et ADD), mais séparer en 3 sql_alter ne résout pas grand chose tant que je ne vois pas comment faire ce DROP column là...

Je pourrais faire un truc spécifique pour ces referrers en sqlite (vider la table visite_veille, copier visites_jour, vider visite jour, mais on sera néanmoins confronté un jour ou l'autre à des mises à jour qui vont faire DROP|ALTER column et qu'il faudra bien savoir gérer... Donc ce n'est pas une solution qui me semble correcte.

MM.

6

Le 12 déc. 07 à 10:12, Matthieu Marcillaud a écrit :

Committo,Ergo:sum a écrit :

Bravo Mathieu. Ca me fait bien plaisir que mon travail de cet été
fasse des petits. Et je suis surpris que tu aies dû changer aussi peu
de choses dans abstract_sql, je m'attendais à des abstractions
supplémentaires à mettre au point, tu es sûr que tout marche a priori ?

Et une question: ça t'a pris combien de temps ?

1) ça m'a pris grosso modo 2 semaines jour et nuit (soit depuis la fin
de mon précédent boulot)
Le plus long c'est de trouver les bonnes infos sur SQLite (il y en a
peu) et de dénicher les petits bugs (inc/auth, j'ai mis du temps !)
En tout cas, tes abstractions sont excellente. Il reste que SPIP se base
sur un nommage MySQL et qu'il faut tout traduire à partir de ce langage,
ça fait beaucoup d'analyses php pour chaque requète du coup.
Mais ce n'est pas encore fini, finalement, car :

2) Non, tout ne marche pas (enfin, presque tout marche hein ^^), j'ai
découvert une erreur hier sur la mise à jour des réferrers et là je n'ai
pas encore eu d'idée lumineuse !
Voilà ce qu'il se passe : SQLite ne gère pas "ALTER TABLE table
(DROP|ALTER) column" et il y a une requète dans /genie/popularites.php :

sql_alter("TABLE spip_referers DROP visites_veille,
        CHANGE visites_jour visites_veille INT(10) UNSIGNED NOT NULL
DEFAULT '0',
        ADD visites_jour INT(10) UNSIGNED NOT NULL DEFAULT '0'");

set requete est une optimisation de la requetes
UPDATE set visites_veille=visistes_jour,visites_jour=0
qui prenait des heures sur les grosses bases sql
on peut la reserver à mysql peut etre

Qui fait en plus d'un DROP, 2 autres actions en même temps (CHANGE et
ADD), mais séparer en 3 sql_alter ne résout pas grand chose tant que je
ne vois pas comment faire ce DROP column là...

Je pourrais faire un truc spécifique pour ces referrers en sqlite (vider
la table visite_veille, copier visites_jour, vider visite jour, mais on
sera néanmoins confronté un jour ou l'autre à des mises à jour qui vont
faire DROP|ALTER column et qu'il faudra bien savoir gérer... Donc ce
n'est pas une solution qui me semble correcte.

oui le probleme vient surtout des maj dans base/upgrade ...
Cedric

7

Le 12 déc. 07 à 09:37, Ben. . a écrit :

ouais, un bon argument "marketing" pour la sortie de la W.X le Y/Z/200[7|8] :wink:

Author: marcimat@free.fr
Date: 2007-12-10 14:41:39 +0100 (lun, 10 déc 2007)
New Revision: 10935

Log:
Intégration d'un portage SQLite

et qui donc relance la question du nom de cette version, dont j'aimerais quand même bien qu'elle sorte en 2007.

Un point déjà: en ce qui concerne la valeur de la variable interne $spip_version donnant un numéro de version de la base déduit du nom de la version de SPIP, on pourrait déjà convenir que ce numéro est plutot celui du dernier dépot SVN ayant changé la base (ou son interprétation, il y a qq cas comme ça). C'est assez facile de prendre cette nouvelle convention, et ça donne plus de liberté pour nommer la prochaine version de SPIP.

Emmanuel

8

Committo,Ergo:sum a écrit :

tu es sûr que tout marche a priori ?

sql_alter("TABLE spip_referers DROP visites_veille,
        CHANGE visites_jour visites_veille INT(10) UNSIGNED NOT NULL
DEFAULT '0',
        ADD visites_jour INT(10) UNSIGNED NOT NULL DEFAULT '0'");

oui le probleme vient surtout des maj dans base/upgrade ...
Cedric

Normalement, le problème des ALTER devrait être résolu, j'ai musclé le script (remarquez le jeu de mots !) pour qu'il réussisse à les faire. La seule solution proposée chez SQLite pour ce genre de chose est de copier le contenu de la table à modifier dans une table temporaire, puis de recréer la table avec les modifications et enfin de recopier le contenu de la table temporaire vers la nouvelle.

Tout cela est donc très gourmand je présume si l'opération se fait sur une grosse table.

La requete ci-dessus se réalise en 3 requetes (chaque ',' est vu comme une requete, ce qui pourrait être amélioré), dont 2 (DROP et CHANGE) qui vont créer chacunes une table temporaire pour se faire.

MM.

9

Matthieu Marcillaud a écrit :

Committo,Ergo:sum a écrit :

tu es sûr que tout marche a priori ?

sql_alter("TABLE spip_referers DROP visites_veille,
        CHANGE visites_jour visites_veille INT(10) UNSIGNED NOT NULL
DEFAULT '0',
        ADD visites_jour INT(10) UNSIGNED NOT NULL DEFAULT '0'");

oui le probleme vient surtout des maj dans base/upgrade ...
Cedric

Normalement, le problème des ALTER devrait être résolu, j'ai musclé le script (remarquez le jeu de mots !) pour qu'il réussisse à les faire. La seule solution proposée chez SQLite pour ce genre de chose est de copier le contenu de la table à modifier dans une table temporaire, puis de recréer la table avec les modifications et enfin de recopier le contenu de la table temporaire vers la nouvelle.

Tout cela est donc très gourmand je présume si l'opération se fait sur une grosse table.

La requete ci-dessus se réalise en 3 requetes (chaque ',' est vu comme une requete, ce qui pourrait être amélioré), dont 2 (DROP et CHANGE) qui vont créer chacunes une table temporaire pour se faire.

MM.

Dans le cas de cette requette, peut être serait il opportun de verifier le type de serveur avant d'envoyer l'existante, ou l'ancienne (un simple update), car il s'agit d'une optimisation pour mysql, dommage que ca pourrisse le cas sqlite...
Cedric