🌍
Français
z0rglub a écrit:
rub a écrit:
z0rglub a écrit:
Je ne vois pas trop quoi d'autre que la base de données pourrait nécessiter une procédure aussi avancée.Par exmple, simplement supprimer des fichiers php qui ne servent plus (fichiers supprimés ou déplacés)...
Pour cet exemple, Subversion s'en occupe parfaitement (mieux que PhpWebGallery ne saurait le faire).
Subversion? C'est à dire?
Je ne vois pas combien comment?
Attention, je ne me place pas en dév mais au niveau installation utilisateur.
rub a écrit:
z0rglub a écrit:
rub a écrit:
Moi, c'est simplement db et database qui me gene, car on peut être amener à faire d'autre update que des update de base de données....
Je ne vois pas trop quoi d'autre que la base de données pourrait nécessiter une procédure aussi avancée.
Par exmple, simplement supprimer des fichiers php qui ne servent plus (fichiers supprimés ou déplacés)...
Pour cet exemple, Subversion s'en occupe parfaitement (mieux que PhpWebGallery ne saurait le faire).
rub a écrit:
z0rglub a écrit:
La méthode par dump, c'est juste la plus simple dans mon mode de fonctionnement. Tant que tu mets correctement à jour le fichier install/phpwebgallery_structure.sql conformément à la sortie de la commande mysqldump, on se fiche de la méthode.
C'était simplement pour proposer x methodes dans le wiki...
Si tu veux proposer une autre méthode, pourquoi pas, mais bon je répète que peu importe la méthode personnelle de travail, ce qui importe c'est ce qu'on commit dans Subversion, et cela doit être conforme à la sortie de mysqldump :-)
z0rglub a écrit:
rub a écrit:
Moi, c'est simplement db et database qui me gene, car on peut être amener à faire d'autre update que des update de base de données....
Je ne vois pas trop quoi d'autre que la base de données pourrait nécessiter une procédure aussi avancée.
Par exmple, simplement supprimer des fichiers php qui ne servent plus (fichiers supprimés ou déplacés)...
z0rglub a écrit:
La méthode par dump, c'est juste la plus simple dans mon mode de fonctionnement. Tant que tu mets correctement à jour le fichier install/phpwebgallery_structure.sql conformément à la sortie de la commande mysqldump, on se fiche de la méthode.
C'était simplement pour proposer x methodes dans le wiki...
rub a écrit:
Moi, c'est simplement db et database qui me gene, car on peut être amener à faire d'autre update que des update de base de données....
Je ne vois pas trop quoi d'autre que la base de données pourrait nécessiter une procédure aussi avancée.
rub a écrit:
Je parlais simplement de la façon de génerer le code sql pour la création de la table par dans quel script il fallait le mettre...
La méthode par dump, c'est juste la plus simple dans mon mode de fonctionnement. Tant que tu mets correctement à jour le fichier install/phpwebgallery_structure.sql conformément à la sortie de la commande mysqldump, on se fiche de la méthode.
z0rglub a écrit:
rub a écrit:
o Pourquoi nommer le fichier xxx-database.php, alors qu'il est indiqué que les modifs sont pour le sql ou php ou autres?
Comment voudrais-tu les nommer ? J'aurais pu faire juste install/db/xxx.php mais je voulais qu'avec la commande "ls -v" les fichiers s'affichent dans le bon ordre (je te laisse faire des essais pour comprendre les soucis que j'ai rencontré en choisissant la nomenclature).
Moi, c'est simplement db et database qui me gene, car on peut être amener à faire d'autre update que des update de base de données....
z0rglub a écrit:
rub a écrit:
o Concernant le point 3 (dump de la structure de la base), pourquoi forcement mettre à jour le fichier install/phpwebgallery_structure.sql par dumping. Perso, je procéde autrement.
Je ne crée pas ma table avec une interface mais directment en commande sql, et à chaque modif, je drop et recrée la table. (Surtout pour une nouvelle table). Par conséquent, j'ai déjà le code source nécessaire. Ne peut-on pas présenter les 2 methodes?Le fichier install/phpwebgallery_structure.sql est utilisé pour une installation "from scratch". Ta méthode, qui revient à mettre une requête SQL de création de table dans install/db/xxx-database.php, est utile pour les mise à jour entre les développeurs et pour les testeurs en BSF principalement.
Je pense qu'on s'est mal compris!!!
Je parlais simplement de la façon de génerer le code sql pour la création de la table par dans quel script il fallait le mettre...
rub a écrit:
o Sur les numéros de version 43 ou 14.2. Pour la BSF, ok c'est le numéro suivant. Mais pour une branche stable, il faut concatener quoi? Peux-tu donner un exemple plus précis?
Sur le wiki, j'ai ajouté un exemple de graphe des numéros. J'espère que c'est plus clair.
+------------+
| branch BSF |
+------------+
|
| +------------+
| | branch 1.6 |
43 => | +------------+
44 => | |
+-----------+
| | <= 44.1
| |
45 => | |
| | <= 44.2
46 => | |
| |
| | <= 44.3
| |
47 => | |
| |
| |
| |
48 => | | <= 44.4
| | <= 44.5
49 => |
|
50 => |
| +------------+
51 => | | branch 1.7 |
52 => | +------------+
53 => | |
+-----------+
54 => | | <= 53.1
| |
55 => | | <= 53.2
| |
| |
| | <= 53.3
|
|rub a écrit:
Et comment va-t-on faire le lien entre un fichier dans BSF et branche stable alors que les noms de fichiers sont différents? Par exemple, je veux ajouter un table phpwebgallery_user_mail_notification . Je crée dans BSF 47-database.php. Comment va-t-on reprendre le fichier 47-database.php dans la branche stable? Quel nouveau nom aura-t-il?
On ne fait pas le lien. De toute façon, pour ce genre d'ajout, il n'y aura qu'un fichier, sur BSF, car il s'agit d'une évolution et pas d'un correction de bug.
rub a écrit:
o Pourquoi nommer le fichier xxx-database.php, alors qu'il est indiqué que les modifs sont pour le sql ou php ou autres?
Comment voudrais-tu les nommer ? J'aurais pu faire juste install/db/xxx.php mais je voulais qu'avec la commande "ls -v" les fichiers s'affichent dans le bon ordre (je te laisse faire des essais pour comprendre les soucis que j'ai rencontré en choisissant la nomenclature).
rub a écrit:
o Concernant le point 3 (dump de la structure de la base), pourquoi forcement mettre à jour le fichier install/phpwebgallery_structure.sql par dumping. Perso, je procéde autrement.
Je ne crée pas ma table avec une interface mais directment en commande sql, et à chaque modif, je drop et recrée la table. (Surtout pour une nouvelle table). Par conséquent, j'ai déjà le code source nécessaire. Ne peut-on pas présenter les 2 methodes?
Le fichier install/phpwebgallery_structure.sql est utilisé pour une installation "from scratch". Ta méthode, qui revient à mettre une requête SQL de création de table dans install/db/xxx-database.php, est utile pour les mise à jour entre les développeurs et pour les testeurs en BSF principalement.
Sur le [WIKI=en:dev], je me poses des questions sur la partie "Database upgrade":
o Sur les numéros de version 43 ou 14.2. Pour la BSF, ok c'est le numéro suivant. Mais pour une branche stable, il faut concatener quoi? Peux-tu donner un exemple plus précis? Et comment va-t-on faire le lien entre un fichier dans BSF et branche stable alors que les noms de fichiers sont différents? Par exemple, je veux ajouter un table phpwebgallery_user_mail_notification . Je crée dans BSF 47-database.php. Comment va-t-on reprendre le fichier 47-database.php dans la branche stable? Quel nouveau nom aura-t-il?
o Pourquoi nommer le fichier xxx-database.php, alors qu'il est indiqué que les modifs sont pour le sql ou php ou autres?
o Concernant le point 3, pourquoi forcement mettre à jour le fichier install/phpwebgallery_structure.sql par dumping. Perso, je procéde autrement.
Je ne crée pas ma table avec une interface mais directment en commande sql, et à chaque modif, je drop et recrée la table. (Surtout pour une nouvelle table). Par conséquent, j'ai déjà le code source nécessaire. Ne peut-on pas présenter les 2 methodes?
edit de z0rglub: un peu d'espace entre les paragraphes pour davantage de clarté.