Reprise du message précédent :

$database = new PDO($dsn, 'lol', 'lol', array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
error_log($sqlite_DSN . '  after  ' . $dsn . " - " . print_r($database, true));
if ($create_database && $sqlite_DSN == $dsn) {
    error_log("creating base in " . $sqlite_file);
    $database->exec(file_get_contents('schema.sqlite.sql'));
}

function fetchJson(Job $job) {
    try {
        include_once 'db.php';
        $result = json_encode($job->doIt($database));
        $database = null;
        return $result;
    } catch (PDOException $e) {
        error_log('exception ' . $e->getMessage());
        return json_encode(ko_answer($e->getMessage()));
    }
    die();
}

db.php avait déjà été appelé plus haut dans le code et $database mis à null? include_once ne fait plus rien dans ce cas, et boum!

mais s'il ne fait plus rien, il ne devrait pas me laisser peinard mes variables ?

bah si, mais du coup si dans un bout de code exécuté au-dessus $database a été mis à null tu l'as dans l'os.

facile à vérifier d'ailleurs, remplace include_once par un include simple et vois si t'as le même résultat...

j'ai des erreurs différentes on dirait

y'a moyen d'avoir des stacktraces dans php en cas d'erreur ?

d'ailleurs ça me parait étrange, un include_once de ce style dans une fonction...tu te retrouves avec une variable qui ne va être définie que dans la première fonction qui aura fait l'include, alors qu'elle a plutôt vocation à être globale, non?

http://www.php.net/manual/en/funct [...] ktrace.php ?

je crois qu'il faut que je revoie ce truc.
 
disons que c'est pour avoir le new PDO() dans le bloc de try.catch.
 
mais c'est bizarre, ce truc ne semble inclus qu'une seule fois

bah c'est ce que fait include_once. Il n'inclut le fichier que la première fois que c'est demandé.

c'est bon, j'ai trouvé un deuxième point d'inclusion

maintenant je fais planter chrome et safari avec mon truc

belle perf.
Une boucle infinie qui fait de l'affichage?

Si tu as la main sur le serveur de dev http://xdebug.org/

j'ai trouvé, quand tu fais un json_encode(json_encode(blabla)) le deuxième voit une chaine de caractères assez balaise (1700chars) qu'il encode sans pb, mais à l'autre bout du tuyau ça se passe assez mal.
 
Merci, je suis décoincé.  
Il m'a fallu que 4h pour faire le GET de la première entité ça se présente pas mal le passage de toute l'appli en REST

merci, j'ai vu passer ça mais j'ai pas encore testé. Au prochain bug chiant, peut-être.

$stmt = executeQuery($pdo, "SELECT lol
             FROM mecouilles
                WHERE user_id=mescouilles AND user_login = ?"
        , array($this->login));
        return $stmt->fetchAll();

salut les jeunes, j'ai un petit pb avec mon code.
Techniquement j'encode direct la réponse de ça avec json_encode().
le problème c'est que toutes les colonnes dont indexées en double dans le tableau de réponse : un coup par nom et un coup par numéro.
 
du coup le json est un peu moche avec toutes les données en double :  

 
vous savez comment éviter ça sans me fatiguer ?

merci

doctrine pour avoir un schéma et des requêtes SQL portable entre différentes bases de données, ça vous paraît bien ?

oui ( je l'utilise en ce moment sur un projet mysql  / SQL server)
par contre attention a ne pas trop utilser de requetes en dur

La base du source de PHP est trop pourrie, le passage à l'unicode est compromis sur PHP 6, ils recommencent tout.
 
http://blog.developpez.com/julienp [...] s-mailing/
 

ouch

La bonne nouvelle, c'est qu'on aura peut-être plus vite les traits (pseudo-héritage multiple) et le type-hinting de scalaire...

trop cool.

heritage multiple > bof  
 
type hinting , ça c'est un bonne chose, mais ça ne changera pas la vie

c'est quoi une requête en dur ? une requête native ?

Le type hinting sur les scalaires, c'est essentiel, c'est une des features dont je regrette le plus l'absence sur 5.2 et 5.3

oui , tupeux passer du SQL natif, et c'est mal

 
quand on voit la merde que ça a été en python, c'était à prévoir

En quoi

si ça vient avec le polymorphisme, alors oui ,ce sera très utile

Doctrine 2 jartant les Behaviours, ça va commencer à être pratique (par ex).

ah ok. Pour ça je gère t'inquiètes pas.

T'entends quoi par polymorphisme ? Ou plutot t'entends quoi que PHP n'aie pas déja ?

function pwet(Agent $agent)
{
 
}
 
function pwet(Agent $agent,Sexe $sx)
{
 
}
 
function pwet(Ornithorynque $duckbillplatipus)
{
 
}

le totu sans avoir a jongler avec les parametres qui ont des valeurs par défaut magiques

 
Vu le niveau global du field de developpeurs php, je suis plutot content de pouvoir formaliser mes types d'entrée. C'est b/d oui, mais il faut bien ca.

function pwet(Agent $agent)
{
 
}
 
function pwet(Agent $agent,Sexe $sx)
{
 
}
 
function pwet(Ornithorynque $duckbillplatipus)
{
 
}

ça va troller chérie ...

flo> jamais on aura ça dans php...ça ferait exploser trop de vieux code.

remarque, topac PHP un vendredi ... c'est happy hour.

Tu veux du rab'? Le type hinting de php me casse les burnes de toute manière, figure 1 :
 

<?php
 
class Foo{
 
    function bar(){
        echo 'hello', PHP_EOL;
    }
}
 
function baz(Foo $f){
    echo 'lolilol de toute manière je me sers pas de $f';
}
 
baz(null);

 
(Vous noterez le fantastique "Catchable fatal error".)

...et pitié je veux pouvoir hinter array(MaClasse)