grum a écrit:

Eric a écrit:

Mais tous les plugins n'ont pas forcément le besoin de stocker leur configuration tout en utilisant des tables supplémentaires.

rajouter une entrée dans la table CONFIG de piwigo ne coûte rien ;-)

Un peu quand même...
Sachant que le contenu entier est lu à chaque fois...

Et ce qui me gêne, c'est que c'est une "bidouille" à faire pour chaque plugin.
On a une table #_plugin, des méthodes d'installations et d'activation. Pourquoi ne pas gérer le stockage de la version dans le coeur de piwigo (d'ailleurs, c'est déjà fait non?) et passer cette version en paramètre des fonctions d'installation et d'activations.

Eric a écrit:

Par exemple, prenons une galerie en 2.0.0 (il y en a qui ne migrent pas leurs galeries) avec des plugins compatibles pour cette version et qui n'ont pas le numéro de version inscrit dans la table Config. Quand il passeront sur Piwigo 2.1, ils devront forcément mettre à jour leurs plugins par la même occasion.

Si il n'y a rien dans la table config, c'est que le plugin n'est pas à jour ;-)

J'ai fait cela dans meta, lors de l'installation du plugin je crée ou met à jour le numéro de version du plugin dans la table config

Tant que le n' de version du plugin dans la table config ne correspond pas au dernier numéro de version du plugin, la partie admin ne propose que de faire une mise à jour du plugin (pour mettre à jour les tables je fini la mise à jour par la table config comme cela si problème lors de la requête l'utilisateur dois recommencer la mise à jour) ).

Si le n° de version du plugin correspond entre la table et mon fichier la partie admin du plugin devient autorisé.

ddtddt parlait du numéro de version dans la tables des plugins.
Le numéro de version est inscrit à l'installation, mais ne bouge pas par la suite.

Perso, je préfèrerai largement rester aux tests de tables qui est bien plus sur, et bien plus pratique...
Nicolas, pourrais-tu vérifier que les requetes SHOW TABLES et SHOW FULL COLUMNS n'existent vraiment pas en postgre et mysql?
Comment comptes-tu gérer l'upgrade de piwigo par la suite?

P@t a écrit:

Perso, je préfèrerai largement rester aux tests de tables qui est bien plus sur, et bien plus pratique...
Nicolas, pourrais-tu vérifier que les requetes SHOW TABLES et SHOW FULL COLUMNS n'existent vraiment pas en postgre et mysql?
Comment comptes-tu gérer l'upgrade de piwigo par la suite?

D'après cette doc et ces commentaires :

For functionality similar to mysql SHOW TABLES use:

select * from information_schema.tables where table_schema='public' and table_type='BASE TABLE'

[edit]

For those coming from MySQL:
SHOW TABLES    = \d
SHOW DATABASES = \l
SHOW COLUMNS   = \d table

However the \* commands only work in psql and not via other interfaces, such as queries via PHP. Similar data can be retrieved with the following SQL commands:

SHOW TABLES (\d) = SELECT table_name FROM information_schema.tables WHERE table_schema = 'public'

SHOW DATABASES (\l) =  SELECT datname FROM pg_database;

SHOW COLUMNS FROM table (\d table) =  SELECT column_name FROM information_schema.columns WHERE table_name ='table';

Il semblerait que oui pour PostgreSql. A voir pour Sqlite.

Dernière modification par Eric (2010-04-05 13:59:53)

Eric a écrit:

Cette discussion semble au point mort. Pourtant elle a suscité des réactions intéressantes.

Alors? Où va nous?

Nulle part. Je ne suis toujours pas convaincu de l'utilité.

nicolas a écrit:

Mise à jour du [Bugtracker] ticket 1570. Eric la balle est dans ton camp !

Vu, merci Nicolas. Malheureusement, je ne fais que passer, en coup de vent. Pas beaucoup de dispo (proche de zéro) en ce moment et ce n'est pas prévu de s'arranger avant le début du mois de juin, dans le meilleur des cas.

Je veux m'attribuer le bug car mon point de vue sur le sujet n'a pas changer: Pourquoi se priver de fonction php/mysql sous prétexte qu'elles n'existent pas forcément nativement pour les autres SGBD supportés?
D'autant que MySql n'est pas mort et demeure une référence solide chez de nombreux hébergeurs. Quand bien même Oracle aurait sa peau, il y a déjà Maria (fork de MySql) sur les rails...

Bref, ok pour le relais. Je prends!

Mais faut me laisser du temps, beaucoup de temps, pour m'y mettre. Et quand je pourrais m'y mettre, j'aurais certainement besoin de quelques coups de main ;-)

Je m'attaque à l'ajout de deux fonctions MySql et leur équivalent Sqlite et PgSql: mysql_num_fields() et mysql_list_fields()

Pour le premier, trouver la correspondance était facile: mysql_num_fields() = sqlite_num_fields() = pg_num_fields(). Mais j'ai un problème avec la correspondance pdo_sqlite, ne connaissant absolument rien à cette mouture "orienté objet". Mes recherches et lectures sur le sujet m'ont amenées à cette solution mais j'ai de gros doutes:

function pwg_db_num_fields($result) 
{
  global $pwg_db_link;
  
  return $pwg_db_link->sqlite_num_fields($result);
}

C'est là que j'aurais bien besoin d'un coup de main ;-)

Pour mysql_list_fields(), cela va être une autre paire de manche... Il n'y a pas de correspondances "toutes faites" et il faudra construire le résultat attendu par des requêtes spéciales. Mais çà, ce sera dans un second temps.

nicolas a écrit:

Avant de te lancer tête dans le guidon tu ne veux pas faire une petite pause et réfléchir deux secondes.

'suis pas certain de savoir vraiment comment prendre cette remarque... Quoi qu'il en soit, je ne suis pas "dans le guidon", je n'en suis qu'à la phase de réflexion et recherche de solutions. Je n'ai pas posé une seule ligne de code mais j'écris toutes les pistes que je trouve pour un problème donné.

nicolas a écrit:

Je persiste à dire que ces fonctions n'ont aucun intérêt. De même que la fonction mysql_num_rows().

Et pourtant mysql_num_rows() est utilisé dans les fichiers functions_sqlite.inc.php, functions_pdo-sqlite.inc.php et functions_pgsql.inc.php pour construire pwg_query(). D'après ce que j'en comprends (et je peux comprendre de travers), se passer de cette fonction à cet endroit est faisable mais cela ne reviendrait-il pas à passer par la lune pour aller à la boulangerie du coin?

nicolas a écrit:

Ne veux-tu pas attendre le développement de la fonction upgrade pour les plugins : [Bugtracker] ticket 1681 ?

De mon côté, y a pas le feu au lac. Je suppose que le but de cette fonction est de proposer un système de mise à jour normé pour les plugins avec une facilité de prise en charge des versions passées?

nicolas a écrit:

Je pense que tu t'es trompé. Ce n'est pas sqlite2 que nous utilisons mais sqlite3 :
http://fr2.php.net/manual/fr/book.sqlite3.php
Pas de méthode sqlite_num_fields() ou quoi que ce soit d'approchant mais tu as la méthode numColumns() :
http://fr2.php.net/manual/fr/sqlite3res … olumns.php

Dans le même esprit, tu as columnName() et columnType():
http://fr2.php.net/manual/fr/sqlite3res … mnname.php
http://fr2.php.net/manual/fr/sqlite3res … mntype.php

Pour PDO c'est la méthode columnCount() pour le nombre de colonnes.

Voilà pour le peu d'aide que je peux t'apporter.

Après je te conseille d'installer une base sqlite et une posgresql. Tu peux t'aider de mon plugin pour migrer et tester.

Je me disais aussi... Les infos que je trouvais étaient parfois contradictoires ou pas du tout en phase avec ce que je lis dans le code de Piwigo.
Sinon, je connais un peu postgresql pour utiliser ce SGBD au boulot (j'aime pas - question d'habitude, je suppose). Je saurais installer çà. Pour Sqlite, faut que je me documente d'abord.