Je stocke des données dans une base MySql pour les extraire ensuite etc.
Après un "import MySQLdb" sous Python-2, les commandes de création,
insertion/remplacement et select fonctionnent lors des tests.
Parallèlement, je teste diverses distros juste pour me confirmer le fait
que j'ai bien raison d'utiliser celle que j'utilise (Slack-13), mais
sait-on jamais...
Dans ce cadre, je vois que mon appli pose de menus problèmes avec la
Slack-14.0 (ce qui n'est pas le sujet de ce post), qu'elle fonctionne
correctement avec CentOS 6, Linux Fermi mais qu'elle est HS avec la
Debian-7. Le problème dans ce cas est que la base de données reste vide
après les commandes insert et/ou replace.
Si je tape des commandes à la main dans une session mysql avec
l'identifiant/mot-de-passe qui va bien, elles fonctionnent. Autre test :
si je remplace MySql par MariaDb, rien ne change.
Je suppose donc que le souci vient du module MySQLdb.
Quelqu'un aurait déjà rencontré ce problème ?
[Xpost f.c.o.l.c, f.c.divers et f.c.l.python, suivi sur ce dernier]
--
Hervé
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas
Bonjour,
Le 01/10/2013 11:48, Herve Autret a écrit :
Bonjour,
Je stocke des données dans une base MySql pour les extraire ensuite etc. Après un "import MySQLdb" sous Python-2, les commandes de création, insertion/remplacement et select fonctionnent lors des tests.
Parallèlement, je teste diverses distros juste pour me confirmer le fait que j'ai bien raison d'utiliser celle que j'utilise (Slack-13), mais sait-on jamais...
Dans ce cadre, je vois que mon appli pose de menus problèmes avec la Slack-14.0 (ce qui n'est pas le sujet de ce post), qu'elle fonctionne correctement avec CentOS 6, Linux Fermi mais qu'elle est HS avec la Debian-7. Le problème dans ce cas est que la base de données reste vide après les commandes insert et/ou replace.
Est-ce que ça pourrait être un problème de commit automatique/manuel ?
Si je tape des commandes à la main dans une session mysql avec l'identifiant/mot-de-passe qui va bien, elles fonctionnent. Autre test : si je remplace MySql par MariaDb, rien ne change.
Je suppose donc que le souci vient du module MySQLdb.
Quelqu'un aurait déjà rencontré ce problème ?
[Xpost f.c.o.l.c, f.c.divers et f.c.l.python, suivi sur ce dernier]
Bonjour,
Le 01/10/2013 11:48, Herve Autret a écrit :
Bonjour,
Je stocke des données dans une base MySql pour les extraire ensuite etc.
Après un "import MySQLdb" sous Python-2, les commandes de création,
insertion/remplacement et select fonctionnent lors des tests.
Parallèlement, je teste diverses distros juste pour me confirmer le fait
que j'ai bien raison d'utiliser celle que j'utilise (Slack-13), mais
sait-on jamais...
Dans ce cadre, je vois que mon appli pose de menus problèmes avec la
Slack-14.0 (ce qui n'est pas le sujet de ce post), qu'elle fonctionne
correctement avec CentOS 6, Linux Fermi mais qu'elle est HS avec la
Debian-7. Le problème dans ce cas est que la base de données reste vide
après les commandes insert et/ou replace.
Est-ce que ça pourrait être un problème de commit automatique/manuel ?
Si je tape des commandes à la main dans une session mysql avec
l'identifiant/mot-de-passe qui va bien, elles fonctionnent. Autre test :
si je remplace MySql par MariaDb, rien ne change.
Je suppose donc que le souci vient du module MySQLdb.
Quelqu'un aurait déjà rencontré ce problème ?
[Xpost f.c.o.l.c, f.c.divers et f.c.l.python, suivi sur ce dernier]
Je stocke des données dans une base MySql pour les extraire ensuite etc. Après un "import MySQLdb" sous Python-2, les commandes de création, insertion/remplacement et select fonctionnent lors des tests.
Parallèlement, je teste diverses distros juste pour me confirmer le fait que j'ai bien raison d'utiliser celle que j'utilise (Slack-13), mais sait-on jamais...
Dans ce cadre, je vois que mon appli pose de menus problèmes avec la Slack-14.0 (ce qui n'est pas le sujet de ce post), qu'elle fonctionne correctement avec CentOS 6, Linux Fermi mais qu'elle est HS avec la Debian-7. Le problème dans ce cas est que la base de données reste vide après les commandes insert et/ou replace.
Est-ce que ça pourrait être un problème de commit automatique/manuel ?
Si je tape des commandes à la main dans une session mysql avec l'identifiant/mot-de-passe qui va bien, elles fonctionnent. Autre test : si je remplace MySql par MariaDb, rien ne change.
Je suppose donc que le souci vient du module MySQLdb.
Quelqu'un aurait déjà rencontré ce problème ?
[Xpost f.c.o.l.c, f.c.divers et f.c.l.python, suivi sur ce dernier]
Herve Autret
Bonjour,
Nicolas a écrit:
[avec la Debian-7] la base de données reste vide après les commandes insert et/ou replace.
Est-ce que ça pourrait être un problème de commit automatique/manuel ?
C'est sans doute la bonne piste, merci. Là je viens de faire écraser la Debian par une OpenSUSE mais je vais installer une deb dans virtualbox, pour savoir.
Si je veux utiliser MySql en autocommit, j'imagine que je devrai taper SET AUTOCOMMIT=1 ; dans une session mysql. Quelle sera la portée de la commande ? toute transaction pour tout utilisateur ou juste la session en cours ?
Je suppose donc que le souci vient du module MySQLdb.
Il ne paraît pas possible de modifier le mode AUTOCOMMIT depuis MySQLdb, me gourrai-je ?
à + -- Hervé
Bonjour,
Nicolas a écrit:
[avec la Debian-7] la base de données reste vide après les commandes
insert et/ou replace.
Est-ce que ça pourrait être un problème de commit automatique/manuel ?
C'est sans doute la bonne piste, merci. Là je viens de faire écraser la
Debian par une OpenSUSE mais je vais installer une deb dans virtualbox,
pour savoir.
Sur la page
http://dev.mysql.com/doc/refman/5.0/fr/commit.html
je lis :
vous pouvez configurer MySQL en mode non-autocommit grâce à la commande:
SET AUTOCOMMIT=0
Si je veux utiliser MySql en autocommit, j'imagine que je devrai taper
SET AUTOCOMMIT=1 ; dans une session mysql. Quelle sera la portée de la
commande ? toute transaction pour tout utilisateur ou juste la session en
cours ?
Je suppose donc que le souci vient du module MySQLdb.
Il ne paraît pas possible de modifier le mode AUTOCOMMIT depuis MySQLdb,
me gourrai-je ?
[avec la Debian-7] la base de données reste vide après les commandes insert et/ou replace.
Est-ce que ça pourrait être un problème de commit automatique/manuel ?
C'est sans doute la bonne piste, merci. Là je viens de faire écraser la Debian par une OpenSUSE mais je vais installer une deb dans virtualbox, pour savoir.
Si je veux utiliser MySql en autocommit, j'imagine que je devrai taper SET AUTOCOMMIT=1 ; dans une session mysql. Quelle sera la portée de la commande ? toute transaction pour tout utilisateur ou juste la session en cours ?
Je suppose donc que le souci vient du module MySQLdb.
Il ne paraît pas possible de modifier le mode AUTOCOMMIT depuis MySQLdb, me gourrai-je ?
à + -- Hervé
Herve Autret
Bonjour,
J'ai trouvé du temps pour me remettre aux tests.
Nicolas :
Il ne paraît pas possible de modifier le mode AUTOCOMMIT depuis MySQLdb, me gourrai-je ?
Ceci dit, je pense qu'il est préférable de ne pas utiliser l'autocommit. Une des règles de Python est : "explicit is better than implicit". J'appliquerais cette règle ici aussi.
Ça peut dépendre de ce qu'on fait mais effectivement, le code explicite pose moins de problèmes de réutilisabilité en général. Et si on veut utiliser le "rollback", j'imagine que l'autocommit va devenir gênant.
à + -- Hervé
Bonjour,
J'ai trouvé du temps pour me remettre aux tests.
Nicolas :
Il ne paraît pas possible de modifier le mode AUTOCOMMIT depuis
MySQLdb, me gourrai-je ?
La réponse ici :
http://stackoverflow.com/questions/1028671/python-mysqldb-update-query-
fails
Ah ben si, on peut en effet, merci !
Ceci dit, je pense qu'il est préférable de ne pas utiliser l'autocommit.
Une des règles de Python est : "explicit is better than implicit".
J'appliquerais cette règle ici aussi.
Ça peut dépendre de ce qu'on fait mais effectivement, le code explicite
pose moins de problèmes de réutilisabilité en général. Et si on veut
utiliser le "rollback", j'imagine que l'autocommit va devenir gênant.
Ceci dit, je pense qu'il est préférable de ne pas utiliser l'autocommit. Une des règles de Python est : "explicit is better than implicit". J'appliquerais cette règle ici aussi.
Ça peut dépendre de ce qu'on fait mais effectivement, le code explicite pose moins de problèmes de réutilisabilité en général. Et si on veut utiliser le "rollback", j'imagine que l'autocommit va devenir gênant.