Discussion :

[Sve@r]

Bonjour à tous
Je suis en train de développer une appli Python qui sera interfacée avec MySQL
Mon code Python commence donc par faire un "connect" sur la bdd et récupère l'identifiant de connection qu'il utilisera ensuite jusqu'à la fin.

Je viens de remarquer que si j'interfère avec ma bdd depuis l'extérieur (style en ligne de commande depuis mysql) alors que mon programme est déjà lancé, les modifs que j'y apporte depuis l'extérieur ne sont pas répercutées.
Exemple
1) je lance mon programme
2) je modifie une table depuis l'extérieur
3) dans mon programme je fais un "select * from la table" => les modif apportées en 2) n'apparaissent pas

Pour que les modif apparaissent, faut soit que je quitte mon programme et que j'y revienne, soit que je refasse un connect().

En revanche, si la modif est faite par le programme alors je n'ai pas de problème.

Est-ce quelqu'un a déjà remarqué ce fait ? Est-ce normal ? Je pense qu'il y a un phénomène de bufferisation dans mon programme dû au connect initial que je conserve tel quel mais j'aimerais en être sûr. Si c'est ça c'est pas trop grave, car mon programme n'est pas destiné à être interfacé depuis l'extérieur et si qqqun le fait il saura qu'il lui faut alors quitter le programme puis le relancer. Mais si c'est un bug de MySQLdb...

Merci à tous

[mchk0123]

Salut, non non ce n'est pas du tout un bug, c'est simplement qu'un simple "connect()" à une BDD (MySQL ou autre) cache beaucoup d'options.
Parmis celles-ci les verrous en Lecture/Ecriture, le traitement par lots, ...
Tu utilise qu'elle API Python pour te connecter à MySQL ? (pyMySQL ?)

[Sve@r]

...Parmis celles-ci les verrous en Lecture/Ecriture, le traitement par lots, ...

J'ai cependant pensé à faire du commit de partout...

Tu utilise qu'elle API Python pour te connecter à MySQL ? (pyMySQL ?)

J'utilise MySQLdb http://sourceforge.net/projects/mysql-python

J'ai remarqué aujourd'hui un autre truc => Si je lance 2 fois mon programme, ben les modif de l'un dans ma bdd sont vues depuis l'autre alors que j'étais persuadé que l'autre ne les verrait pas tant qu'il n'aurait pas fait un "connect"...

[mchk0123]

J'ai cependant pensé à faire du commit de partout...

Le commit (si j'ai bonne mémoire), ne t'assure que le lancement de l'exécution d'un lot. En gros, au sein d'un même connection (session), les requêtes sont bufferisée jusqu'au prochain commit (si la session est ouverte en mode lot).

Par contre tu peut avoir une option cachée à ton connect() qui pose un verrou de partage (lecture et/ou écriture) inter-sessions. Et si le SGBD SQL est correctement programmé, il fera attendre toute demande de connection à ton 2ème client le temps que le 1er termine sa session. D'où du coup un effet de rémanence.

J'utilise MySQLdb http://sourceforge.net/projects/mysql-python

Je regarde de plus près comment on passe les options, et je te fait un retour.

J'ai remarqué aujourd'hui un autre truc => Si je lance 2 fois mon programme, ben les modif de l'un dans ma bdd sont vues depuis l'autre alors que j'étais persuadé que l'autre ne les verrait pas tant qu'il n'aurait pas fait un "connect"...

Arf, autant pour moi, c'est alors que c'est ton 2ème client (et pas ton script python) qui pose pb. Tu devrais regardé de ce côté là. Je suppose que tu utilise la console d'admin MySQL comme 2ème client ?

Essaye de lancer 2x ta console (et non pas ton script), je parie ma chemise que le pb. rémanence va revenir.

[Sve@r]

Par contre tu peut avoir une option cachée à ton connect() qui pose un verrou de partage (lecture et/ou écriture) inter-sessions. Et si le SGBD SQL est correctement programmé, il fera attendre toute demande de connection à ton 2ème client le temps que le 1er termine sa session. D'où du coup un effet de rémanence.

Euh non. Là le 2° passera en attente et ne renverra rien tant que le premier n'aura pas libéré ses verrous.

Arf, autant pour moi, c'est alors que c'est ton 2ème client (et pas ton script python) qui pose pb. Tu devrais regardé de ce côté là. Je suppose que tu utilise la console d'admin MySQL comme 2ème client ?

J'utilise une console mode texte lancée par la commande "mysql -u user nom_bdd"

Essaye de lancer 2x ta console (et non pas ton script), je parie ma chemise que le pb. rémanence va revenir.

Héhé... tu me dois ta chemise => les modifs de l'une apparaissent bien dans l'autre

Sympa de chercher mais ce n'est plus trop la peine puisque ça marche dans mon programme. Au début j'ai remarqué le truc parce que j'ai voulu insérer des valeurs "à la main" pour mes tests et j'ai vu que mes valeurs n'apparaissaient pas dans mon programme... mais si les valeurs insérées par l'instance n° 1 de mon programme sont vues par l'instance n° 2, ça me soulage (vu que mon programme est destiné à fonctionner en parallèle sur plusieurs postes connectés à la même bdd...)

[mchk0123]

Pour te donner un exemple de la complexité du verouillage sur MySQL :

http://dev.mysql.com/doc/refman/5.0/...isolation.html

Il y a même des verrouillages / lignes (plutôt que par session ou table !).

Je continu à chercher les options de connect() acceptés par ton API.

[mchk0123]

Toujours envie de comprendre ton problème de "rémanence" ?

Déjà est-ce que tu manipules 1 ou plusieurs tables (programme Python + mysqladmin) ?
Et surtout sur quel type de table ?
Enfin quelle version de MySQL tu utilises (car il y a souvent des changements importants entre versions) ?

[Sve@r]

Pour te donner un exemple de la complexité du verouillage sur MySQL :

http://dev.mysql.com/doc/refman/5.0/...isolation.html

Effectivement, il y a un paquet de trucs...

Toujours envie de comprendre ton problème de "rémanence" ?

Toujours

Déjà est-ce que tu manipules 1 ou plusieurs tables (programme Python + mysqladmin) ?

Pour l'instant j'en suis au début donc je ne bosse que sur une table. En fait, mon code PyQt m'affiche ma table dans une jolie petite fenêtre et c'est en voulant rajouter ou modifier mon jeu d'essais (via mysql en mode "commande") que j'ai découvert le truc.

Et surtout sur quel type de table ?

Excellente question car j'ai vu que cela induisait des contraintes et ça peut effectivement jouer => c'est une table InnoDB car j'ai aussi des contraintes d'intégrité...

Enfin quelle version de MySQL tu utilises (car il y a souvent des changements importants entre versions) ?

5.0.37...

[mchk0123]

Ok,

Donc la documentation que j'ai trouvé concerne la v4.xxx de MySQL, et comme les InnoDB sont apparues avec la v4, j'espère qu'il n'y a trop de différences avec la v5, enfin espérons.

Pour commencer, les tables InnoDB n'ont pas de verrouillage de table par défaut, par contre elles posent par défaut des verrous de lignes pour chaque requête.

D'apres notre discussion je suppose que tu n'appliques pas de verrous de tables avec des commandes du genre "LOCK TABLE" ? Je me trompe ?

Maintenant quel est le niveau de complexité de tes 2 lots de requêtes (1. pour ton appli Python + 2. pour les commandes tapées dans mysqladmin) ?
Autrement dit : nombre de requêtes, et pour chacune nombre de tables mises en jeu, et type de requêtes (INSERT, UPDATE, SELECT et/ou JOIN, ...) ?

Ou bien si elles sont assez simples poste les directement.

[Sve@r]

D'apres notre discussion je suppose que tu n'appliques pas de verrous de tables avec des commandes du genre "LOCK TABLE" ? Je me trompe ?

Tout à fait exact

Maintenant quel est le niveau de complexité de tes 2 lots de requêtes (1. pour ton appli Python + 2. pour les commandes tapées dans mysqladmin) ?
Autrement dit : nombre de requêtes, et pour chacune nombre de tables mises en jeu, et type de requêtes (INSERT, UPDATE, SELECT et/ou JOIN, ...) ?

Ou bien si elles sont assez simples poste les directement.

Attention, je n'utilise même pas "mysqladmin" mais juste la petite console "mysql" en mode texte. Mais rien de vraiment compliqué dans mes requêtes...
Donc j'ai une table personnes qui contient "id, nom, prenom, ..." et je veux afficher ces personnes dans ma widget donc c'est grosso-modo un truc dans ce style

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
curs=bdd.cursor()   # bdd est issu d'un connect() fait au tout début du programme et que je me passe de fonctions en fonctions
curs.execute("select id, nom, prenom from personne order by nom, prenom")
for res in curs.fetchall():
    widget.addItem("%s %" % (res[1], res[2]))
curs.close()

Et pis je veux rajouter en ligne (pour mes tests) qq petits noms en plus, ben j'ouvre une bête fenêtre mysql et je tape

use <nom_de_ma_bdd>;
insert into personne (nom, prenom) values ("Truc", "Machin");

Et je rappelle ma page qui contient ma widget et là, ben je ne vois pas apparaitre "Truc". Ensuite pour en rajouter j'essaye des update, etc mais rien. Faut que je quitte mon appli et que j'y retourne pour que ce que j'ai fait apparaisse.
Donc rien de bien compliqué quoi...

[mchk0123]

1. Question C... je suppose que quand tu dis que la nouvelle ligne n'apparait pas dans ton widget, on est d'accord que ton interpreteur Python re-éxécute bien le bloc de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
curs=bdd.cursor()   # bdd est issu d'un connect() fait au tout début du programme et que je me passe de fonctions en fonctions
curs.execute("select id, nom, prenom from personne order by nom, prenom")
for res in curs.fetchall():
    widget.addItem("%s %" % (res[1], res[2]))
curs.close()

2. Question un peu moins C..., lors de ton insert dans la console, tu est bien sur que aucun autre traitement SQL n'ait lieu dans ton appli ?

Autrement dit que les manips. sont bien :
1. Appli : SELECT -> remplissage widget
... (attente de fin du select / fetchall)
2. Console : INSERT
... (attente du prompt)
3. Appli : clear du widget + ré-exécution du SELECT -> remplissage du widget

PS : pour savoir ou en est exactement ton appli. tu peut faire des :
- print '...' (si la console de l'appli IHM est affichée)
- OU exécuter le code Python en mode debug + breakpoints
- OU lancer des MessageBox de l'API Win32 (via ctype + chargement dll)
- OU trouver une fonction équivalente à celle là dans l'API du toolkit graphique utilisé

[Sve@r]

1. Question C... je suppose que quand tu dis que la nouvelle ligne n'apparait pas dans ton widget, on est d'accord que ton interpreteur Python re-éxécute bien le bloc de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
curs=bdd.cursor()   # bdd est issu d'un connect() fait au tout début du programme et que je me passe de fonctions en fonctions
curs.execute("select id, nom, prenom from personne order by nom, prenom")
for res in curs.fetchall():
    widget.addItem("%s %" % (res[1], res[2]))
curs.close()

Tout à fait puisque tout ce code est inclu dans une fonction qui crée la widget, la remplit via le select et l'affiche à l'écran. Et j'appelle la fonction quand je veux depuis une widget principale de mon appli

2. Question un peu moins C..., lors de ton insert dans la console, tu est bien sur que aucun autre traitement SQL n'ait lieu dans ton appli ?

Autrement dit que les manips. sont bien :
1. Appli : SELECT -> remplissage widget
... (attente de fin du select / fetchall)
2. Console : INSERT
... (attente du prompt)
3. Appli : clear du widget + ré-exécution du SELECT -> remplissage du widget

Tout à fait, je n'en suis qu'au tout début de mon appli et je ne traite pour l'instant que les personnes.

Je vais même en rajouter une louche => Ma widget possède un bouton de modification. J'appuie sur ce bouton, cela appelle un update de ma bdd (un simple incrément juste pour test).
Ben si j'ouvre 2 instances de mon programme et que j'effectue les actions suivantes
- pgm1: j'affiche la widget
- pgm2: j'affiche la widget
- pgm2: j'appuie sur le bouton => les infos sont modifiées dans la bdd et je rajoute un commit (parce que j'ai programmé mon serveur pour qu'il n'y ait pas d'autocommit car je veux pouvoir faire du rollback s'il y a un problème)
- pgm1: je ferme la widget
- pgm1: je réouvre la widget (toute la phase select + addItem s'exécute) => je ne vois pas apparaitre les nouvelles infos
- pgm2: je réouvre la widget (toute la phase select + addItem s'exécute) => je vois apparaitre les nouvelles infos.
- pgm1: je quitte mon pgm et je le relance et j'ouvre la widget => je vois apparaitre les nouvelles infos.

Pas évident mais ce n'est pas non plus catastrophique. Dans le pire des cas j'en serai quitte pour mettre un connect() à chaque fois que j'accède à ma bdd...

[mchk0123]

Une première idée qui vient comme ça ... tu as essayer de modifier la localisation de ton curseur (côté client vs. serveur) ?

Je continu à étudier le problème en attendant.

PS : il existe aussi une nature sur les curseurs Static / Dynamic / ... etc.

PS2: laisse tomber j'avais pas vu le close() sur le curseur, donc pas la peine de le changer (au pire essaye "curs = None" après le close() histoire de désallouer l'objet Python)

[mchk0123]

Quelques pistes (une seule ligne à la fois) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
connect('...', sql_mode='TRADITIONAL')
connect('...', sql_mode='ANSI')
connect('...', sql_mode='MYSQL323')
connect('...', sql_mode='MYSQL40')
connect('...', sql_mode='MSSQL')

Et aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
bdd.query("UNLOCK TABLES")
curs=bdd.cursor()   # bdd est issu d'un connect() fait au tout début du programme et que je me passe de fonctions en fonctions
curs.execute("select id, nom, prenom from personne order by nom, prenom")
for res in curs.fetchall():
    widget.addItem("%s %" % (res[1], res[2]))
curs.close()

[Sve@r]

A la réflexion, je me demande même s'il ne faudrait pas fonctionner comme suit :

1. simplifier l'exemple, en revenant à la configuration par défaut :
- sans modifier le type d'accès à la table (option auto-commit)
- sans utiliser de curseur
- éventuellement utiliser une table MyISAM
- ... et autre non-trivialité du genre

2. retester le pb. rémanence
- si c'est ok, ont est sur la bonne voie

3. - modifier la configuration, étape par étape (curseur -> serveur -> table ...)
- retester à chaque étape jusqu'à apparition du pb. de rémanence
- dés pb. c'est que l'on a localiser la source du pb.

Vu - Je fais ça dès lundi. Je peux aussi essayer PyMySQL...

[mchk0123]

EDIT: également d'autres pistes dans mon poste ci-dessus.

[Sve@r]

EDIT: également d'autres pistes dans mon poste ci-dessus.

Quelques pistes (une seule ligne à la fois) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
connect('...', sql_mode='TRADITIONAL')
connect('...', sql_mode='ANSI')
connect('...', sql_mode='MYSQL323')
connect('...', sql_mode='MYSQL40')
connect('...', sql_mode='MSSQL')

Pas encore testé

Et aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
bdd.query("UNLOCK TABLES")
curs=bdd.cursor()   # bdd est issu d'un connect() fait au tout début du programme et que je me passe de fonctions en fonctions
curs.execute("select id, nom, prenom from personne order by nom, prenom")
for res in curs.fetchall():
    widget.addItem("%s %" % (res[1], res[2]))
curs.close()

Je viens de tester le UNLOCK ça ne change rien. Mais j'ai découvert un nouveau fait important
Test1
a) Je lance mon appli => elle fait le connect
b) j'ouvre MySQL
c) j'ouvre la fenêtre => elle affiche les infos
d) je modifie via MySQL les infos
e) je ferme la fenêtre et je la réouvre => les infos n'ont pas changé

Test2
a) Je lance mon appli => elle fait le connect
b) j'ouvre MySQL
c) je modifie via MySQL les infos
d) j'ouvre la fenêtre => elle affiche les infos qui ont été modifiées

On dirait que au moment où j'utilise les ressources (test1) il y a mémorisation en cache et c'est le cache qui est réaffiché en e) Et dans le test2, ben le cache est vide donc il est chargé au moment du d) avec ce que contient la bdd. et j'ai rajouté aussi "curs=None" mais sans effet.

Sinon le UNLOCK ne change rien. J'ai pas encore testé le reste. Mais si je remplace UNLOCK par un nouveau connect() alors plus de pb.

[mchk0123]

Bien, on commence a y voir plus clair.

Une dernière chose, comment tu réalise ton connect ?
Tu passes par un DSN ?
Si c'est le cas regarde dans dans le gestionnaire ODBC de Windows sur la DB concernée.
Je sais que pour le driver MySQL ODBC tu à un bouton + onglet détails/options avancées. Et regarde si tu n'as pas des options sur le type de lock & de cache.

A noter le fait important que certains types de lock impliquent l'utilisation d'un cache entre les Read & Write (par. ex. notamment l'utilisation du lock Optimistic sous VB).

[Sve@r]

Bien, on commence a y voir plus clair.

Une dernière chose, comment tu réalise ton connect ?
Tu passes par un DSN ?

Non, j'avais juste installé le serveur MySQL pour windows. Et je suis aussi sur Linux en semaine.

Je viens d'installer le driver ODBC et je l'ai configuré mais ça ne change rien. Je pense qu'il faut se baser sur le curseur. A propos, comment tu peux obtenir une doc sur ça ? J'ai essayé "help(MySQLdb)" mais j'obtiens la liste complète des objets sans vraiment plus de détail. Je suis allé voir sur sourceforge mais sans rien y trouver comme doc...

[mchk0123]

Je viens d'installer le driver ODBC et je l'ai configuré mais ça ne change rien.

Tu as bien regardé la doc du driver MySQL Odbc ?

Ici : http://dev.mysql.com/doc/refman/5.0/...iguration.html
Ici : http://dev.mysql.com/doc/refman/5.0/...reference.html
Et ici : http://dev.mysql.com/doc/refman/5.0/...sagenotes.html

Je pense qu'il faut se baser sur le curseur. A propos, comment tu peux obtenir une doc sur ça ?

Je suis pas pleinement sûr que le pb. vienne uniquement du curseur, mais pourquoi ne pas essayer ? Les 2 choses que tu peut faire, c'est de changer de type de curseur MySQLdb ou de supprimer complètement l'utilisation d'un curseur.

Pour le premier test, tu peut essayer de changer Cursor() par SSCursor() qui utilise un curseur placé sur le serveur (alors que le curseur par défaut est situé sur le client).

J'ai essayé "help(MySQLdb)" mais j'obtiens la liste complète des objets sans vraiment plus de détail. Je suis allé voir sur sourceforge mais sans rien y trouver comme doc...

Moi non plus, je n'ai pas trouvé de doc sur MySQLdb, j'ai carrément lu le code source dans le répertoire d'installation (un peu documenté).