Reprise du message précédent :

Avec PDO c'est prepare + execute pour avoir du prepared.
Ca fait qu'une instruction en +

<?php
$con=mysqli_connect("example.com","peter","abc123","my_db" );
// Check connection
if (mysqli_connect_errno())
  {
  echo "Failed to connect to MySQL: " . mysqli_connect_error();
  }
 
mysqli_query($con,"INSERT INTO Persons (FirstName, LastName, Age)
VALUES ('Peter', 'Griffin',35)" );
 
mysqli_query($con,"INSERT INTO Persons (FirstName, LastName, Age)
VALUES ('Glenn', 'Quagmire',33)" );
 
mysqli_close($con);
?>

 
 
Ok merci donc ma syntaxe est bonne?

Surtout que mieux vaut étendre PDO pour gérer les transactions sans avoir à se poser la question de savoir si tu en as commencé une ou pas. Donc ajouter une petite méthode qui prend une chaine SQL (ou un truc pour récupérer ta chaine si tu les stockes quelque part) et un array, ce n'est pas la mort.

ca se fait encore des queries SQL sans passer par une couche d'abstraction ?
 
ca revient a faire du web en java mais en mettant tout le code dans un JSP, ou a faires des queries sans utiliser hibernate ou assimilé
 
 
sinon nginx ca poutre du cheval mort ! par contre c'est un peu plus long a configurer qu'apache.
une solution simple c'est d'abord de l'utiliser en proxy (un apt-get et 5mn de conf), ca impacte pas trop le fonctionnement d'une appli et ca permet de voir ce qui est prioritaire niveau perfs

Ça double le nombre d'instructions, et execute(array) ça marche que si tous tes paramètres sont des PDO::PARAM_STR, si t'as un autre type impliqué t'as gagné le droit de te taper du bindParam

WTF?

Oui

Non (mais alors vraiment pas)

 
Quand on sait ce qu'on fait et qu'on veut un truc très light, oui

Personnellement je serais incapable de faire certaine requêtes SQL en passant par une surcouche, je pourrais sans doute apprendre mais ça me semble quand même plus simple d'écrire directement du SQL que d'apprendre à expliquer à un PDO PHP ce que je veux qu'il demande à MySQL .

Wat?

Tu réalises que PDO c'est juste une API générique pour requêter toutes les DBs sans avoir à se taper une API spécifique pour chaque? Et tu gagnes en bonus des bindparams nommés (pas juste numériques)? Pour "expliquer à PDO ce qur tu veux qu'il demande à MySQL", bah tu crées ta connection en lui filant le dsn, puis tu fais tes requêtes normalement. Et c'est pareil avec postgres, mssql, oracle, sqlite, informix ou autres.

Un PDO classique tu peux déjà tout faire avec lui, genre select()->from()->join()->where->group() ... etc.

 
quelle partie? la comparaison JSP?
parce que c'est exactement ne pas utiliser un ORM type hibernate (meme si hibernate fait vachement de trucs en plus)
 
apres qu'il puisse y avoir des avantages en terme de perf a faire du SQL direct je le nie pas, mais on oublie les problematiques des SQL differents selon les sgbdr et leur versions (super quand on change de version majeure...), on traite les commit/rollback a la main, on traite le lazy load a la main (certaines db sont plus rapides sans jointures dans la query, d'autres non)
donc ouais si on maitrise tout ca (env, versions) c'est "acceptable" mais je suis pas sur que ce soit vraiment la panacée.
 
quand a apprendre a faire un descripteur de relations ou a faire les bind lors des queryies c'est vraiment pas sorcier, ca prends 20mn a tout peter de savoir monter faire son descripteur des lors qu'on a un MCD/MPD
 
et il y a l'embarras du choix, en hibernate on peut faire du HQL, utiliser les annotations, doctrine, torpedo...
doctrine etant supporté par quasiment tous les frameworks c'est un investimment viable qui pour moi va dans le sens de l'apprentissage du framework.
 
[EDIT]
je parle bien de queries a l'ancienne, pas de PDO.
mais pdo, c'est un query builder comme torpedoquery, pas un full ORM

Je suis une feignasse et je n'aime pas les transactions imbriquées.

http://php.net/manual/fr/book.pdo.php
C'est de la query à l'ancienne hein, pas un "query builder".

PDO-l'API-PHP c'est pas un querybuilder. C'est rien de plus q'une API de connection et requêtage pluggable et gérant des DBs multiples, comme DBI, DBAPI2 ou JDBC.

Bah ça tombe bien, MySQL non plus (pas plus que Postgres ou que nombres de libs de connection DB genre ODBC ou ADO). Les transactions imbriquées sont faites explicitement via SAVEPOINT.

Et franchement dans un process web c'est vraiment le truc le plus con du monde: tu ouvres une transaction avant de commencer ton processing, tu la commit à la fin si pas d'erreur, tu rollback si erreur. Tu peux ajouter des custos configurés (genre pour pas ouvrir de transaction quand t'as pas besoin d'une connection DB), mais c'est vraiment pas sorcier et t'as aucune raison de ne pas savoir si une transaction est en cours ou non (bon après dans DBAPI, sauf si t'es en autocommit une transaction est automatiquement ouverte à la première requête)

ah oui tiens, autant pour moi.
mais effectivemment j'utilise plus ca depuis des lustres.
 
a partir du moment ou une condition est rajoutée en fonction d'un test/argument je voyais plus trop l'interet de builder une string de cette maniere
 
je prefere largement le chaining :
http://torpedoquery.org/
 
[edit]
mais en php je fais plutot du doctrine (symfony) et/ou les formats natifs des frameworks (i.e cake)

 
En faisant ça tu crée une fonction non composable, contrairement à une logique genre "tu ouvres si la transaction au debut si elle est pas ouverte, tu la fermes à la fin si c'est toi qui l'a ouverte". Après c'est pas forcément un prérequis absolu d'avoir des fonctions composables jusqu'à tout en haut, mais des fois c'est cool.

Je vois pas ce qu'avoir besoin d'un contexte d'exécution a de non-composable, bien au contraire même (ça permet d'exécuter la fonction en dehors d'un mode transactionnel classique avec une db mockée par exemple, si la fonction commence à bricoler les transaction de son côté c'est plus possible).

L'état transactionnel, c'est du cross-cut, ça n'a rien à foutre dans les fonctions de processing imo.

À ma connaissance tous les fw python un peu sérieux fonctionnent de cette manière, avec des hooks pour des sous-transactions si besoin: https://docs.djangoproject.com/en/d [...] p-requests http://docs.sqlalchemy.org/en/rel_ [...] -questions (seconde moitié de la 2e question)

Mes objets ne sont pas sensés savoir si la méthode qu'on appelle d'eux se fait dans une transaction ou pas. Donc ils en commencent une et la terminent eux-même si besoin. Et si en fin de compte cette partie était au milieu d'une plus large transaction, le wrapping de pdo s'est démerdé pour ne faire qu'un begintransaction au départ.

Donne :

Ce que je trouve très bien.

Ce que je trouve pas très bien (pour les raisons indiquées au dessus: c'est pas leur boulot de s'occuper de ça, ce me semble être une flagrante violation de SRP et plus si affinité)

<?php
$test = new PDO('mysql:dbname=test;host=127.0.0.1', '', '');
$test->beginTransaction();
$test->beginTransaction();

Bah oui comme je l'ai dit mysql aime pas les transactions nestées.

C'est un choix. Je considère que mon objet sait mieux que quiconque si les appels qu'il fait dans ses méthodes risquent de mettre la merde en base ou pas si une erreur survient.
 

Une des faiblesses de PDO à mon avis, ce genre de truc devrait être abstrait pour avoir le même comportement autant que possible entre les drivers.

J'ai modernisé mon bac à sable. Passage HTML5 et giclage de la compatibilité IE. Ça change la vie
 
Pour la grille, j'ai pris ça. Any comments ?

 
Un bout de code qui inconditionnellement démarre une session n'est plus appelable librement par un autre bout de code qui voudrait jouer avec des sessions, c'est dans ce sens là qu'avoir un point où on dit "bon là c'est une opération entière, j'enrobe le contenu avec un begin/commit/rollback et c'est ok" me dérange. C'est précisément aussi ce qu'on voit dans la doc de SQLAlchemy, ça parle de requêtes, d'opérations, d'unit-of-work, que l'on enrobe chacune d'une transaction, je trouve ça un peu dommage si ensuite je peux pas combiner ces opérations pour faire des opérations plus grandes (D'autres trouveront que de toute façon si l'opération est plus grande, il faudra forcément l'implémenter différemment au niveau SQL pour avoir de bonnes perfs, donc que c'est une bonne chose, par exemple, de ne pas laisser les gens facilement boucler sur une opération simple pour implémenter une grosse opération).
 
Ceci dit la logique conditionnelle dont je parlais, j'imaginais pas la foutre directement dans le corps de chaque fonction, d'autant plus que c'est tout le temps la même. Et le fait d'avoir du noop quand t'es dans une db mockée, c'est le même comportement attendu quand tu exécutes une opération au sein d'une autre opération plus grande.

Votre RTE préféré, en inline & contenteditable (pas d'iframe)?

Sceditor, tout simple, personnalisable, standard.

C'est une iframe, et c'est pas inline.

En quoi c'est mal de faire un DB::Query() avec ma requête direct au lieu de passer par select()->from()->join()->where->group() ?
Dans un environnement php / MySQL, je ne vois vraiment pas ce que j'ai à gagner à passer par un objet de 300 lignes...

Redactor, mais je suis pas certain de ce que tu entends exactement par inline.

Qui se place directement sur du contenu existant, pas une iframe, textarea ou autre avec un éditeur "formel" séparé.
 
Genre http://ckeditor.com/demo#inline

Je suis pas d'accord 'ou j'ai pas compris )
Si dans ma fonction j'enchaîne 2 requêtes, faut que dans ma fonction je fasse un begin/commit non ?

Non. Si dans ta fonction t'enchaînes 2 requêtes, ben t'enchaînes 2 requêtes et c'est tout, la gestion transactionnelle c'est pas ici qu'elle doit se faire. La seule situation où tu begin/commit c'est si ta fonction est suffisamment bas niveau pour avoir et avoir eu besoin de créer une connection, mais normalement ça c'est fait uniquement dans les "points d'entrée" de l'application/du framework.

Cupra

Ou cupra pas, mais avec une hache c'est plutôt cupra en effet

Impossible de valider un choice field rempli en AJAX avec Symfony2
 
C'est pas la première fois que je me heurte à ce problème et je ne trouve rien de concret sur le net...
Des experts dans le coin ?

Le fait d'encapsuler au sein de la fonction te garantit que c'est géré à son niveau. T'as pas à déléguer aux couches appelantes des détails d'implém (qu'est-ce qu'elle en sait la couche appelante qu'elle doit initier une transaction ?)

C'est à dire? Ça fait quoi?

 
J'ai un select dépendant d'un autre. Au départ ce select est vide (un array vide lui est passé). En fonction de la valeur sélectionnée par l'user dans le premier select je rempli le second en faisant un appel ajax à une méthode me retournant un JSON.

Je développe un bout d'appli@home, elle envoi des mails qui sont détectés comme spam par le SMTP de Free.
Quoi comme service gratuit pour envoyer quelques mails par mois ?

Créer une transaction c'est pas un détail d'implémentation, c'est un problème sémantique. Et c'est bien l'une des couches appelantes (pas nécessairement l'appelant direct) qui doit être en charge de configurer, organiser et synchroniser le système.

Ta fonction qui fait le boulot, elle a sûrement pas à décider de committer son bordel, parce que l'appelant peut très bien vouloir un grain plus épais, ou autre.

mailjet
(avec possibilité d'enregistrer son domaine pour éviter le spam)

mailchimp/sendgrid?