En DBAL, ORM minimaliste (et un seul fichier) , il y a http://www.redbeanphp.com
Le 17 août 2013 09:15, Thibault CORDIER <thibault.cord...@gmail.com> a écrit : > > > Le 17 août 2013 09:09, Nicolas <nikro...@gmail.com> a écrit : > > Le 16 août 2013 22:33, Pep <p...@callmepep.org> a écrit : >> >> > -----Message d'origine----- >> > De : dev-boun...@list.dotclear.org [mailto: >> dev-boun...@list.dotclear.org] >> > De >> > la part de Nicolas >> > Envoyé : vendredi 16 août 2013 20:53 >> > >> > > entre une classe non testée unitairement et du code éprouvé, lequel >> > choisis-tu ? D'ailleurs le support de SQLite se fait déjà via PDO ! >> > >> > Désolé mais, pour moi, un code testé unitairement ne suffit pas à être >> > qualifié de code "éprouvé". >> > >> >> On est d'accord. >> >> >> > Un code éprouvé, c'est quelque chose qui tourne correctement en >> production, >> > depuis plusieurs années et sur quelques centaines d'installations. >> > >> >> Et quand il est testé unitairement et tournent sur des millions >> d'installations pendant des années, est-ce qu'on peut considérer qu'il est >> éprouvé ? >> >> >> > Alors, oui, je suis sans doute de la vieille école : si je considère >> que le >> > TDD est un plus non négligeable vers la qualité du code, il n'est en >> rien >> > une panacée. C'est un peu comme les diplômes : au mieux ça filtre les >> plus >> > mauvais éléments, en rien ça ne te garantit les meilleurs. >> > >> >> Je n'ai pas parlé de TDD mais juste de tests unitaires. Je pense que tu >> n'as pas dû faire assez de tests unitaires. Certes, le fait de tester ne >> garantie pas la meilleure qualité du code sur le court terme, mais en >> rejoignant ce que tu disais au dessus, sur le long terme, avec ce code mis >> en prod pendant des années on se rapproche du meilleur code possible de >> façon plus certaine sans regression. >> >> > >> > Quant au support de SQLite via PDO, il faudrait que je te retrouve les >> > échanges à ce sujet, juste histoire de rigoler. Dans mes souvenirs, le >> > passage a été fait contraint et forcé à cause de l'incapacité de >> l'équipe >> > PHP à l'époque à se décider sur le support ou non en natif de SQLite, >> > quelle >> > version, quelle forme. >> > >> > Là c'est une autre histoire comme tu dis et ce n'est pas nécessairement >> la >> faute de ceux qui l'ont codé. De mémoire, dans PHP, le support de SQLite >> en >> version 2 se faisait en natif ou PDO et pour la version 3, uniquement avec >> PDO. >> >> >> > > dbschema est certes intéressant mais à des limites aussi et a les >> mêmes >> > faiblesses que dblayer. >> > >> > Je n'en doute pas. Mais quelles sont-elles concrètement ? >> > Et ma question porte plus sur la partie exploitation en production (et >> > développement de plugins, à la limite) que sur l'aspect maintenance du >> > code. >> > >> > Il n'y a pas de gestion des auto-incréments par exemple. Je n'ai jamais >> compris pourquoi cela n'a pas été fait. >> Je ne me souviens plus précisément les problèmes que j'avais rencontré >> mais >> j'avais fini par faire le schéma à la main ce qui est vraiment dommage. >> >> Là pour dbschema je ne connais pas d'équivalent qui ne soit pas énorme >> mais >> je ne connais pas toutes les librairies... >> >> Nicolas >> -- >> Dev mailing list - Dev@list.dotclear.org - >> http://ml.dotclear.org/listinfo/dev >> > > -- Dev mailing list - Dev@list.dotclear.org - http://ml.dotclear.org/listinfo/dev
