Gouvernance ToPIA : bonnes configuration par défaut vs principe de moindre surprise
Je suis face à un choix et il n'y a rien de prévu dans les règles de gouvernance ToPIA sur ce sujet. Je suis donc face à un dilemme. Dans le cadre du ticket #2892, nous sommes en train de faire en sorte de réduire au maximum la configuration nécessaire à ToPIA. Pour cela, dès qu'on peut fixer une valeur par défaut qui peut être bonne pour la majorité des cas ou qui suit une bonne pratique, on le fait. Sauf que là, ça s'oppose à deux autres principes souhaitables : 1/ souhait de rétro-compatibilité (pour moi, c'est pas un souci car on travaille sur une version majeure) 2/ le principe de moindre surprise qui veut qu'un composant fonctionne a priori comme on s'y attendra, et donc on pourra s'attendre à ce que ToPIA, basé sur Hibernate, ait comme comportement par défaut celui d'Hibernate (donc ne pas changer les valeurs par défaut). En l'occurence, il s'agit de fixer la naming strategy d'Hibernate. Par défaut, Hibernate (et donc ToPIA 2 et, je suppose, une majorité de nos projets) utilisent la DefaultNamingStrategy alors que la bonne pratique veut qu'on utilise la ImprovedNamingStrategy. Donc soit option 1) ToPIA démarre Hibernate avec, par défaut, la ImprovedNamingStrategy parce que c'est la bonne pratique mais certains projets basés sur ToPIA 2 (pas ceux qui démarreront sur ToPIA 3) devront avoir une ligne de configuration en plus (ça qui me paraît pas la mer à boire) pour assurer la compatibilité avec ToPIA 3 (à moins de migrer les bases mais ça me paraît fou) option 2) On laisse tel quel, car c'est ainsi que fonctionne Hibernate par défaut et donc c'est à Hibernate de faire le choix de faire évoluer la valeur par défaut C'est un cas particulier mais je voudrais généraliser ça à une règle de gouvernance ToPIA qui indiquera désormais laquelle de ces deux voies on préconise. À vos avis. P.S : l'immense partie anglophone de notre gigantesque communauté d'utilisateurs de ToPIA me pardonnera ce mail en français. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Le 28/01/2015 11:17, Brendan Le Ny a écrit :
Sauf que là, ça s'oppose à deux autres principes souhaitables : 1/ souhait de rétro-compatibilité (pour moi, c'est pas un souci car on travaille sur une version majeure) 2/ le principe de moindre surprise qui veut qu'un composant fonctionne a priori comme on s'y attendra, et donc on pourra s'attendre à ce que ToPIA, basé sur Hibernate, ait comme comportement par défaut celui d'Hibernate (donc ne pas changer les valeurs par défaut).
En l'occurence, il s'agit de fixer la naming strategy d'Hibernate. Par défaut, Hibernate (et donc ToPIA 2 et, je suppose, une majorité de nos projets) utilisent la DefaultNamingStrategy alors que la bonne pratique veut qu'on utilise la ImprovedNamingStrategy.
Tu as une source concernant cette bonne pratique de ImprovedNamingStrategy ? Car si c'est une bonne pratique, pourquoi hibernate ne l'utilise pas en lieu et place de DefaultNamingStrategy ?
Donc soit
option 1) ToPIA démarre Hibernate avec, par défaut, la ImprovedNamingStrategy parce que c'est la bonne pratique mais certains projets basés sur ToPIA 2 (pas ceux qui démarreront sur ToPIA 3) devront avoir une ligne de configuration en plus (ça qui me paraît pas la mer à boire) pour assurer la compatibilité avec ToPIA 3 (à moins de migrer les bases mais ça me paraît fou)
option 2) On laisse tel quel, car c'est ainsi que fonctionne Hibernate par défaut et donc c'est à Hibernate de faire le choix de faire évoluer la valeur par défaut Je vote pour l'option 2 (parce que je n'ai pas d'argument pour voter pour l'option 1).
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 28/01/2015 16:54, Eric Chatellier a écrit :
Tu as une source concernant cette bonne pratique de ImprovedNamingStrategy ?
Peu importe, c'est pas ma question. Je pose la question en général, ça vaut aussi pour le pool de connexion, par défaut Hibernate n'est a pas alors qu'il en faut un etc donc est-ce qu'on en met un par défaut ou pas ? Pour le cas particulier de la NamingStrategy, elle est « Improved », c'est marqué dessus, j'sais pas ce qu'il te faut ! :)
Car si c'est une bonne pratique, pourquoi hibernate ne l'utilise pas en lieu et place de DefaultNamingStrategy ?
Rétro-compatibilité je suppose.
Je vote pour l'option 2 (parce que je n'ai pas d'argument pour voter pour l'option 1).
Ouais mais tu vote juste sur la namingstrategy : soit, mais c'est plutôt le cas général qui m'intéresse. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Le Wed, 28 Jan 2015 11:17:17 +0100, Brendan Le Ny <bleny@codelutin.com> a écrit :
Je suis face à un choix et il n'y a rien de prévu dans les règles de gouvernance ToPIA sur ce sujet. Je suis donc face à un dilemme.
Dans le cadre du ticket #2892, nous sommes en train de faire en sorte de réduire au maximum la configuration nécessaire à ToPIA. Pour cela, dès qu'on peut fixer une valeur par défaut qui peut être bonne pour la majorité des cas ou qui suit une bonne pratique, on le fait.
Sauf que là, ça s'oppose à deux autres principes souhaitables : 1/ souhait de rétro-compatibilité (pour moi, c'est pas un souci car on travaille sur une version majeure) 2/ le principe de moindre surprise qui veut qu'un composant fonctionne a priori comme on s'y attendra, et donc on pourra s'attendre à ce que ToPIA, basé sur Hibernate, ait comme comportement par défaut celui d'Hibernate (donc ne pas changer les valeurs par défaut).
En l'occurence, il s'agit de fixer la naming strategy d'Hibernate. Par défaut, Hibernate (et donc ToPIA 2 et, je suppose, une majorité de nos projets) utilisent la DefaultNamingStrategy alors que la bonne pratique veut qu'on utilise la ImprovedNamingStrategy.
Donc soit
option 1) ToPIA démarre Hibernate avec, par défaut, la ImprovedNamingStrategy parce que c'est la bonne pratique mais certains projets basés sur ToPIA 2 (pas ceux qui démarreront sur ToPIA 3) devront avoir une ligne de configuration en plus (ça qui me paraît pas la mer à boire) pour assurer la compatibilité avec ToPIA 3 (à moins de migrer les bases mais ça me paraît fou)
option 2) On laisse tel quel, car c'est ainsi que fonctionne Hibernate par défaut et donc c'est à Hibernate de faire le choix de faire évoluer la valeur par défaut
C'est un cas particulier mais je voudrais généraliser ça à une règle de gouvernance ToPIA qui indiquera désormais laquelle de ces deux voies on préconise.
À vos avis.
Hello ! Dans ma façond e comprendre ta question me vient une réponse par une nouvelle question : est-ce que Topia est une simple encapsulation|surcouche de Hibernate ? Je vois plutot Topia comme une lib qui s'appuie sur Hibernate, et donc, par là, qu'elle peut très bien avoir sa conf par défaut qui n'est pas celle d'Hibernate. S'ils nous est possible de suivre une bonne pratique, alors j'ai tendance à penser que c'est par là qu'il faut aller, même si cela signifie ne pas être dans la conf par défaut de Hibernate. Avec la version 3, je suppose qu'il y aura un guide de migration, et donc l'information sera présente. Comme tu dis, c'est une version majeure, s'il y a des lignes de conduite à changer/fixer, c'est mieux que ce soit maintenant. Je vote donc pour la 1, car je ne pense pas que ce soit à Hibernate de dicter le comportement de Topia, mais à Topia d'avoir sa philosophie et de configurer Hibernate comme il entend l'utiliser. -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28
On 28/01/2015 11:17, Brendan Le Ny wrote:
option 1) ToPIA démarre Hibernate avec, par défaut, la ImprovedNamingStrategy parce que c'est la bonne pratique mais certains projets basés sur ToPIA 2 (pas ceux qui démarreront sur ToPIA 3) devront avoir une ligne de configuration en plus (ça qui me paraît pas la mer à boire) pour assurer la compatibilité avec ToPIA 3 (à moins de migrer les bases mais ça me paraît fou)
Pour moi ToPIA doit faire au mieux, quitte à casser la rétrocompatibilité. Arnaud
participants (4)
-
Arnaud Thimel -
Brendan Le Ny -
Eric Chatellier -
Yannick Martel