Eric a écrit:
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é.
Non il ne faut pas le prendre mal. C'était à relier à ma remarque sur la demande d'évolution (fonction upgrade).
Cela me fait penser à une remarque encore entendu aujourd'hui. Quand tu as un besoin d'un utilisateur, n'y réponds pas tout de suite et quelque fois le besoin disparait.
Ce que j'essaie de te dire, c'est que la fonction upgrade te permettra (enfin j'espère) de te passer de ces fonctions et permettra de faire une mise à jour de tes plugins bien plus simples et bien plus sûr.
Eric a écrit:
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?
Encore une fois, ce n'était qu'une première étape pour ne pas faire peur à tout le monde. Je n'ai pas de lien sous la main mais le fait d'utiliser mysql_num_rows() pour savoir si la requête à renvoyer un ou des enregistrements n'est pas une très bonne pratique à mon sens.
Eric a écrit:
nicolas a écrit:
Ne veux-tu pas attendre le développement de la fonction upgrade pour les pluginsAprè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.
C'est un autre débat mais en deux mots (sinon ouvre une autre discussion), pourquoi n'aimes-tu pas postgresql ? Pour ma part c'est le contraire, depuis que j'ai découvert je ne supporte plus les défauts de mysql.
Pour sqlite, tu as juste besoin d'installer le suport dans php. Il n'y a rien d'autres à faire.
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.
Avant de te lancer tête dans le guidon tu ne veux pas faire une petite pause et réfléchir deux secondes. Je persiste à dire que ces fonctions n'ont aucun intérêt. De même que la fonction mysql_num_rows().
Ne veux-tu pas attendre le développement de la fonction upgrade pour les plugins : [Bugtracker] ticket 1681 ?
Eric a écrit:
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:Code:
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 ;-)
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 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.
Eric a écrit:
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 ;-)
Pas de problème.
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 ;-)
Mise à jour du [Bugtracker] ticket 1570. Eric la balle est dans ton camp !
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é.
Cette discussion semble au point mort. Pourtant elle a suscité des réactions intéressantes.
Alors? Où va nous?
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.
P@t a écrit:
ddtddt parlait du numéro de version dans la tables des plugins
N'as-tu pas lu un peu vite? Dans ses propos, ddtddt ne mentionne que la table Config et pas la table Plugins ;-)
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?
Oui mais question performances, comme l'a souligné Rub, la table config est parcourue à chaque fois. Ceci dit, faut que je fasse des tests pour mes plugins.
En général, une modification dans la structure ou le contenu des tables dédiées au plugin donne lieu à un changement de version majeure (2.14 vers 2.15 par exemple). Il faudrait que j'inscrive le numéro de version dans la table config et que je teste sur les 4 premiers digit. A voir...
Mais, pour revenir sur le problème de fond de ce topic, il serait tout de même bien de pouvoir vérifier les structures des tables. A un moment ou à un autre, ces fonctions viendront à manquer à quelqu'un.
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é.
+1