djano a écrit 1147 commentaires

Elle promet un gain d'environ 15% en termes d'instructions par cycle d'horloge

En nombre d'instructions par cycle d'horloge?

Il y a 2 typos dans la dépêche.

Une:

Si ensuite je décide que que tout le trafic réseau sortant sur l'interface eth0

Et deux:

Si Vinton Cerf à raison et que que chacun des acteurs trouve un intérêt égoïste

Il est donc rassurant de constater que des simplifications sont encore possibles sans impact sur les performances.

Ce n'est pas l'avis de l'article LWN qui comme dans de tel changements dit: "il n'est pas a exclure qu'il y ait des régressions avec certaines charges de travail spécifiques".

Je suis sur que tu as déjà plein de super idées, mais j'ai une idée stupide que je ne peux m’empêcher de partager: pourquoi pas faire comme les rétroliens (trackbacks) des blogs?

Petit correction:

Désolé, mais la le proprio est juste mieux pour toi actuellement, temporairement dans ce cas

Dans le cas de RMS, je suis sur que son PC est totalement libre!
Son seuil de résistance est hyper haut!

 

En tout cas, c'est marrant, vous faites la discussion inversée par rapport au début, ou précédemment Xavier Claude poussait Zenitram a être plus libre, alors que maintenant Zenitram pousse Xavier Claude a être plus libre :)

C'est une idée, quoique fondamentaliste (ou intégriste d'ailleurs) est plutôt péjoratif actuellement :)

En fait, Gitorious ou Github je m'en fous un peu et chacun fait comme il veut.

Mais je ne suis pas d'accord avec tes arguments: tu compares le service que rend Github avec le service que rend Gitorious.

la liberté d'étudier le fonctionnement de l'adapter à ses besoins: Impossible avec github. Si il te manque une fonctionalité, ou qu'un détail de ne plaît pas, tu ne peux rien y faire.

Vrai. Mais au final, tu peux aussi avoir le même résultat avec le site gitorious. Les gars derrière Gitorious peuvent
1. refuser ta contribution
2. refuser d'activer ta contribution sur leur site pour x raisons même si ils l'ont accepté dans le dépot. Genre, tu fournis une contribution qui consiste à permettre de gérer des dépôts Subversion, cela ne veut pas dire que les administrateurs de Gitorious vont accepter d'activer cette fonctionnalité sur leur site (parce qu'ils ne veulent pas s’embêter à gérer des serveurs subversions par ex).

Donc tu ne seras pas plus avancé en utilisant les services du site Gitorious.

Si, car tu peux changer d’hébergeur si Gitorious ne te convient plus, et tu peux même t'auto-héberger si ça te chante en faisant toues les modifs que tu veux sur le source code de Gitorious!

Je ne dis pas que c'est facile ou pratique quoique ça peut rapidement l’être selon les buts d'une organisation (J'ai bien compris que ce n'était pas tes buts).
Je ne sais pas comment faire ça avec GitHub.

La liberté d'améliorer et de publier les amélioration: Impossible avec github.

C'est vrai. Mais ça rejoint le point deux : ça ne va pas dire que ça va changer le service que propose le site Gitorious.

Mais puisque tu peux publier tes modifications, quelqu'un d'autre que toi pourrait se saisir de ces modifications et monter un service équivalent a Gitorious correspondant plus a tes besoins (avec la fonctionnalité que tu veux, avec le prix qui te convient, etc.).
Github ne permet pas ça.

Conclusion : que le site repose entièrement sur des logiciels libres ou pas, cela ne change absolument rien sur le service rendu dans l'absolu. Cela dépend simplement du bon vouloir des administrateurs du service. CQFD.

Autre conclusion: Si le site repose entièrement sur des logiciels libres, cela permet de démarrer / trouver / changer pour un service qui correspond mieux a ses propres besoin dans l'absolu. Cela dépend simplement de tes besoins. CQFD.

Libriste idéologiste/idéologue?

En effet, je ne savais pas qu'il y avait tout ça dans Oracle! (Un serveur JMS!!)

Mais tout ça a du sens si l'on pense a tout ce dont une BD Oracle est capable, une fois debuggé, pourquoi ne pas le fournir aux utilisateurs et appliquer les même standards de documentation?

Je dois avouer que je suis bluffé par les rapports de perfs avec AWR et comment OEM rend cela facile. Je me demandais justement si PostgreSQL avait un équivalent aux AWR? Apparemment oui: [dans http://blog.postgresql.fr/index.php?post/2009/04/28/Nouveaut%C3%A9s-PostgreSQL-8.4], chercher "fonctions de monitoring" (explain plan, pg_stat_statements, pg_statsinfo). Je ne sais pas a quel point cela peut être comparé avec les AWR d'Oracle, mais je suppose que cela a été amélioré depuis.

C'est vrai que la doc Oracle est bonne - merci de me la faire découvrir - mais j'ose espérer que la doc pour PostgreSQL est également bien fournie.

Je ne sais pas si PostgreSQL a l'équivalent de tout ce que tu mentionnes - probablement pas (Je ne vois pas quel intérêt ils auraient à avoir un serveur JMS :) ) - mais ils font des progrès conséquents à chaque nouvelle version, ce qui est pas mal du tout pour une base de donnée libre et développée entièrement par une communauté plutôt qu'une entreprise.

je constate que 100% des développeurs avec qui j'ai eu l'occasion de travailler sont convaincus que un update bloque obligatoirement un select sur la même donnée : il y a donc toutes les chances de trouver du code qui s'appuie sur ce comportement pour implémenter une logique métier.

Ça vient sûrement du fait qu'ils ont pu "s’entraîner" sur une base Oracle, et pas forcément sur aucune autre dans le cadre des cours.

Je ne connais pas HSQLDB mais tu devrais peut-être vérifier que ton application ne s'appuie pas (peut-être sans que ce soit volontaire) sur ce comportement Oracle.

Je suis sur que ce comportement existe dans l'appli, mais puisque HSQLDB ne sera vraiment utilisé que pour exécuter les tests d’intégration, avec une base dédiée par test (single thread), donc on devrait éviter les écueils que tu cite :)

MVCC et update contre update

Tu soulèves des questions bien intéressantes. Tout ceci m'a l'air dépendant de l’implémentation si le standard ne définit rien en ce sens. Sachant dans quelles conditions le standard se trouve actuellement, je ne serais pas surpris que 1) la norme SQL ne définisse rien 2) personne ne le vérifie de toute manière alors comme d'habitude chaque vendeur le fait a sa manière.

MVCC et triggers

Heureusement pour nous, on n'a quasiment pas de triggers, et pas dans les cas que tu cites, alors on est tranquille de ce côté!

Merci beaucoup de me prévenir des différents problèmes auxquels je pourrais faire face! ;)

En fait, c'est pire : selon que le (+) est attaché aux colonnes d'une table ou d'une autre, il va s'agir d'un left outer join ou d'un right outer join (détails ici, et plus bas pour savoir pourquoi ce "bidule" existe).

Tout a fait! Je suis passé un peu vite sur la chose.

Tu as peut-être du code qui date un peu, non ?

Même pas, c'est quelqu'un qui a trouvé ça plus rapide, mais je trouve ça carrément mois compréhensible pour le premier venu.

C'est donc plutôt une mauvaise nouvelle car, en pratique, cela signifie qu'il n'existe plus de standard.

Tiens je ne m'étais jamais posé la question de qui validait les implémentations, mais je considérais plutôt le standard SQL que comme une base syntaxique que chaque vendeur était libre de suivre… ou pas! Je ne pense pas que les vendeurs de bases de données compatibles SQL soient intéressés pour collaborer a ce qu'une telle certification existe, et surtout pas le principal vendeur actuel: Oracle.

Je n'ai peut être pas été assez clair, mais HSQLDB ne supporte pas la syntaxe table.col dans un INSERT (mais a qui cela sert donc dans ce cas?), sinon il n'y a bien sûr aucun problème avec une requête SELECT.

Oui le '+' n'est vraiment pas simple a comprendre lorsque l'on lit le code SQL, heureusement qu'ils supportent la clause standard avec LEFT OUTER JOIN.

Hou là, là, mais faut qu’on nique ?! Quuooi ? Qu’est ce qu’il y a ? Attends, tu crois que je t’ai juste invité pour te payer un verre d’eau ? Mais j’suis pas un goujat quand même !…

Bah, ne le prend pas mal, ça fait partie du folklore et de l'historique local. Les comptes créés pour l'occasion pour troller ont fait partie intégrante de l'histoire du site, avec ce que l'on appelle les "multi" (les utilisateurs avec plusieurs comptes).

Ça vient du fait que le site est ouvert (comme l'open source), il est donc plus facile pour les trolleurs de venir faire des dégâts tout en ne faisant aucune contribution positive. La communauté se blinde contre ça, mais du coup il est plus difficile pour un nouvel entrant de s'y habituer.

Bref, ce n'est pas personnel, et tu as bien prouvé que tu avais de la ressource pour répondre.
Il y a également un historique de personnes qui ont un avis différent de l'opinion moyenne du site (PasBill PasGates, Zenitram), et bien je peux te dire qu'il faut avoir la peau dure!

Au plaisir de lire tes commentaires futurs.

Dites donc le sujet devient très intéressant :)

Je me mêle a la conversation car nous essayons actuellement de remplacer Oracle par HSQLDB pour exécuter les tests d’intégrations sur notre logiciel, car HSQLDB dispose d'un mode de compatibilité avec Oracle (syntaxe, mais je ne suis pas sur pour l’exécution (De toute façon, c'est configurable). J'ai entendu dire que H2 avait aussi une compatibilité avec Oracle, mais je ne l'ai pas essayé.

Il y avait bien sûr les minimes différences syntaxiques facilement corrigées dans le code de l'appli:

-- utiliser le nom de la table avec la colonne ne marche pas dans HSQLDB
INSERT INTO TABLE_NAME (TABLE_NAME.COL1, TABLE_NAME.COL2) VALUES ("", "")

-- HSQLDB n'aimait pas ces parenthèses:
SELECT *
FROM TABLE1 (LEFT OUTER JOIN TABLE2 ON ...)

-- La syntaxe oracle avec un '+' pour les left outer join:
-- Oracle8i
select last_name, d.department_id
from employees e, departments d
where e.department_id = d.department_id(+);

-- Oracle9i
select last_name, d.department_id
from employees e LEFT OUTER JOIN Departments d
                 ON e.department_id = d.department_id;

Nous avons trouvé quelques autres bugs qui ont été corrigés depuis:

• utilisation de ROWNUM dans des requêtes imbriquées

• différence dans l'implémentation de JDBC

• …

Il y a également des truc plus lourd, genre SELECT COUNT(*) OVER() et START WITH… CONNECT BY PRIOR. Pour START WITH… CONNECT BY PRIOR, le mainteneur de HSQLDB nous suggérait de le remplacer par une requête "WITH RECURSIVE" standard. Pas possible pour nous :( Alors on essaie de rentrer en contact avec le mainteneur de HSQLDB pour qu'il les implémente pour nous.

Heureusement que l'on n'utilise pas MERGE dans notre appli :) Cette instruction ressemble a la méthode merge() dans Hibernate.

Bref au final, ce petit project réalisé pour un logiciel propriétaire (hélas) aura permis d'améliorer un projet libre ce qui peut être permettra a d'autres personnes de sauter le pas et de remplacer Oracle par HSQLDB?

Ha ha! Je comprend que mon commentaire ne t'aie pas du tout plus.

Au temps pour moi, tes commentaires suivant m'ont montré que tu n'était pas celui que je pensais que tu étais, donc je te prie de m'excuser. En effet tes commentaires était très fouillés et je te crois sans hésiter lorsque tu dis qu'il t'as fallu 3-4 heures pour les écrire. Merci de l'avoir fait.

La forme de ton commentaire m'avait donné a penser que c'était copié coller de quelque part. Je me suis visiblement trompé et j'en suis content. Je préfère des commentaires appuyés que les commentaires stériles. Comme baud123 l'a fait remarqué, la date de création de ton compte était suspecte (vieille technique connue par ici), mais je me rappelle avoir créé mon compte dans des circonstances similaires a toi. J'avais lu le siite pendant longtemps avant de vouloir poster un jour et donc de devoir créer mon compte.

Je vais relire un peu tout ça et sûrement revenir avec des commentaires plus pertinents. A plus!

Merci de ta réponse.

Heureusement pour moi je ne suis pas du tout dépendant de Oracle Forms au boulot, sinon j'aurais déjà changé de boulot :) C’était juste un exemple pris comme ça.

J'avais été assez fasciné par le projet NACA, voila une approche raisonnée (petit pas), innovante (Je ne connais pas d'équivalent de remplacement d'une stack complète) et couronnée de succès! Toute mes félicitations a l'auteur du projet.
Je ne savais pas qu'ils avaient créé une boite autour. Je leur adresse tous mes encouragements!

Merci pour vos retours d’expérience, je n'osais pas l'essayer précisément a cause de la synchro des onglets.

Je suis d'accord avec Yves: je préfère avoir le choix de partager les onglets ou pas.

J'imagine que vous avez chacun vos suites de tests, donc utiliser les deux suites de tests pour tester les deux librairies permettra de mieux valider le code.

Un merge est-il envisageable?

Il me semblait que PHP5 permettait d'utiliser les bibliothèques java depuis du code PHP?

Vous pouvez utiliser Maven avec lequel il est facile de faire une séparation propre, surtout sur une projet standalone comme celui-ci.

En plus vous n'aurez pas besoin de mettre les jars externes (Xalan, commons, etc.) dans votre jar.

Au fait, pourquoi ne pas utiliser SLF4J pour le logging ?

Oracle Forms est aussi pas mal dans le genre "je me lie ad vitam æternam avec ma base de données".

C'est une des raisons pour laquelle l'architecture 3 tiers a du succès.

C'est quand même fou le nombre de pseudo qui se sont créés a l'occasion de cette dépêche! :)

Bon ta prose est très jolie, mais elle a quand même l'air un peu trop carrée pour avoir été rédigée comme un commentaire.
Copier / coller avec un peu de changement du texte pour appuyer un peu plus ton disclaimer?

Disclaimer :
* J'espère que tout ceci ne ressemble pas à une publicité pour Oracle car ce n'est pas mon intention, ils ont bien assez de budget pour faire de la pub' sans moi, je ne suis pas attaché à Oracle plus qu'à un autre produit (j'utilise par ailleurs SQL Server et postgres - sur des projets de moindre envergure - et cela donne entière satisfaction).
* Et Oracle n'est pas un produit parfait ni miraculeux, tout le monde s'en doutait !

Bof j'y crois pas, mais comme tu dis: a chacun de juger (ou pas).

My est le prénom de la première fille du créateur de MySQL: Monty Widenius.
Maria est le prénom de la deuxième fille du créateur de MySQL (aussi créateur de MariaDB).

J'ai cru que tu parlais de PostgreSQL! :D