12-07-2018, 03:31 PM
Salut,
il n'est pas nécessaire de démarrer une transaction avant de lancer sa procédure stockée (celle-ci peut ne pas être démarrée du tout, même si ce n'est pas toujours conseillé pour des raisons de consistance, ou celle-ci peut être démarrée dans la procédure elle-même via START TRANSACTION).
A mon avis, le problème se situe plutôt dans l'usage du Framework: le framework doit, normalement, utiliser un client MySQL (mysqli ou PDO, mysqli étant moins intéressant car moins générique et n'offrant pas plus de fonctions que PDO) et une requête doit encore traîner dans ce client sans avoir été fermée lorsque tu fais ton appel à ta procédure stockée.
Ca, ou bien le framework n'est pas capable de gérer les retours des procédures.
En tous cas, je ne recommanderai pas trop les procédures mixées avec ce type de framework (sauf si la doc du framework a un chapitre dédié à l'utilisation des procédures dans ce framework). L'intérêt, en effet, de la procédure face aux requêtes, c'est de n'avoir qu'un seul appel au SQL, et de faire tout le calcul métier (tout le travail nécessaire à la page web) dans cette procédure (je me doute que l'exemple a été simplifié, mais si chaque procédure n'a qu'une seule query, meh, c'est pas utile de passer par les proc). Le framework perd alors très vite de son intérêt (il perd tout son intérêt de DAO, de facade vers le SQL, et de modèle en général). S'il faut vraiment le conserver, j'aurai alors tendance à ne pas utiliser les "DB accessor" (->db->) qu'il propose, et j'ouvrirai une connexion PDO sur la base de donnée moi-même (et éventuellement, je ne déclarerai rien de la BDD au niveau du framework pour qu'il ne s'y connecte pas lui-même).
il n'est pas nécessaire de démarrer une transaction avant de lancer sa procédure stockée (celle-ci peut ne pas être démarrée du tout, même si ce n'est pas toujours conseillé pour des raisons de consistance, ou celle-ci peut être démarrée dans la procédure elle-même via START TRANSACTION).
A mon avis, le problème se situe plutôt dans l'usage du Framework: le framework doit, normalement, utiliser un client MySQL (mysqli ou PDO, mysqli étant moins intéressant car moins générique et n'offrant pas plus de fonctions que PDO) et une requête doit encore traîner dans ce client sans avoir été fermée lorsque tu fais ton appel à ta procédure stockée.
Ca, ou bien le framework n'est pas capable de gérer les retours des procédures.
En tous cas, je ne recommanderai pas trop les procédures mixées avec ce type de framework (sauf si la doc du framework a un chapitre dédié à l'utilisation des procédures dans ce framework). L'intérêt, en effet, de la procédure face aux requêtes, c'est de n'avoir qu'un seul appel au SQL, et de faire tout le calcul métier (tout le travail nécessaire à la page web) dans cette procédure (je me doute que l'exemple a été simplifié, mais si chaque procédure n'a qu'une seule query, meh, c'est pas utile de passer par les proc). Le framework perd alors très vite de son intérêt (il perd tout son intérêt de DAO, de facade vers le SQL, et de modèle en général). S'il faut vraiment le conserver, j'aurai alors tendance à ne pas utiliser les "DB accessor" (->db->) qu'il propose, et j'ouvrirai une connexion PDO sur la base de donnée moi-même (et éventuellement, je ne déclarerai rien de la BDD au niveau du framework pour qu'il ne s'y connecte pas lui-même).