Quand fermer cursors en utilisant MySQLdb

au lieu de demander ce qu'est la pratique standard, puisque c'est souvent imprécis et subjectif, vous pourriez essayer de regarder le module lui-même pour des conseils. En général, l'utilisation du mot-clé with comme un autre utilisateur suggéré est une excellente idée, mais dans ce cas précis, il peut ne pas vous donner tout à fait la fonctionnalité que vous attendez.

depuis la version 1.2.5 du module, MySQLdb.Connection implémente le context manager protocol avec le code suivant ( github ):

def __enter__(self):
    if self.get_autocommit():
        self.query("BEGIN")
    return self.cursor()

def __exit__(self, exc, value, tb):
    if exc:
        self.rollback()
    else:
        self.commit()

il existe plusieurs questions et Réponses sur with déjà, ou vous pouvez lire comprendre Python's" avec "statement , mais essentiellement ce qui se passe est que __enter__ exécute au début du bloc with , et __exit__ exécute à la sortie du bloc with . Vous pouvez utiliser la syntaxe optionnelle with EXPR as VAR pour lier l'objet retourné par __enter__ à un nom si vous avez l'intention de faire référence à cet objet plus tard. Donc, étant donné l'implémentation ci-dessus, voici une façon simple d'interroger votre base de données:

connection = MySQLdb.connect(...)
with connection as cursor:            # connection.__enter__ executes at this line
    cursor.execute('select 1;')
    result = cursor.fetchall()        # connection.__exit__ executes after this line
print result                          # prints "((1L,),)"

la question est maintenant, quels sont les états de la connexion et du curseur après avoir quitté le bloc with ? La méthode __exit__ montrée ci-dessus appelle seulement self.rollback() ou self.commit() , et aucune de ces méthodes n'appelle la méthode close() . Le curseur lui-même n'a pas de __exit__ méthode définie – et ne serait pas important si elle l'était, parce que with est seulement la gestion de la connexion. Par conséquent, la connexion et le curseur restent ouverts après avoir quitté le bloc with . Ceci est facilement confirmé par l'ajout du code suivant à l'exemple ci-dessus:

try:
    cursor.execute('select 1;')
    print 'cursor is open;',
except MySQLdb.ProgrammingError:
    print 'cursor is closed;',
if connection.open:
    print 'connection is open'
else:
    print 'connection is closed'

vous devriez voir la sortie "le curseur est ouvert; la connexion est ouverte" imprimé à stdout.

je crois que vous devez fermer le curseur avant commettre la connexion.

pourquoi? Le MySQL C API , qui est la base de MySQLdb , n'implémente aucun objet curseur, comme indiqué dans la documentation du module: " MySQL ne supporte pas les curseurs; cependant, les curseurs sont facilement émulés." en effet, la classe MySQLdb.cursors.BaseCursor hérite directement de object et n'impose aucune restriction de ce type aux curseurs en ce qui concerne le commit/rollback. Oracle développeur avait ceci à dire :

cnx.commit() avant cur.close() semble très logique pour moi. Peut-être que vous peut suivre la règle: "fermez le curseur si vous n'en avez plus besoin." Ainsi commit () avant de fermer le curseur. En fin de compte, pour Connecteur / Python, il ne fait pas beaucoup de différence, mais ou autre bases de données qu'il peut.

Je m'attends à ce que ce soit aussi proche que vous allez obtenir à" standard la pratique" sur ce sujet.

y a-t-il un avantage significatif à trouver des ensembles de transactions qui ne nécessitent pas de commit intermédiaire de sorte que vous n'ayez pas à obtenir de nouveaux curseurs pour chaque transaction?

j'en doute fort, et en essayant de le faire, vous pouvez introduire une erreur humaine. Mieux vaut décider d'une convention et s'y tenir.

est-il beaucoup de frais généraux pour obtenir de nouveaux curseurs, ou est-ce juste pas une grosse affaire?

le overhead est négligeable, et ne touche pas du tout le serveur de base de données; il est entièrement dans l'implémentation de MySQLdb. Vous pouvez regarder BaseCursor.__init__ sur github si vous êtes vraiment curieux de savoir ce qui se passe lorsque vous créez un nouveau curseur.

en revenant à plus tôt quand nous discutions with , peut-être maintenant vous pouvez comprenez pourquoi les méthodes MySQLdb.Connection classe __enter__ et __exit__ vous donnent un tout nouvel objet curseur dans chaque bloc with et ne vous donnez pas la peine de le suivre ou de le fermer à la fin du bloc. Il est assez léger et n'existe que pour votre confort.

si c'est vraiment important pour vous de gérer l'objet curseur, vous pouvez utiliser contextlib.fermeture pour compenser le fait que l'objet curseur n'a pas méthode définie __exit__ . D'ailleurs, vous pouvez également l'utiliser pour forcer l'objet de connexion à se fermer en sortant d'un bloc with . Cela devrait sortie "my_curs est fermé; my_conn est fermé":

from contextlib import closing
import MySQLdb

with closing(MySQLdb.connect(...)) as my_conn:
    with closing(my_conn.cursor()) as my_curs:
        my_curs.execute('select 1;')
        result = my_curs.fetchall()
try:
    my_curs.execute('select 1;')
    print 'my_curs is open;',
except MySQLdb.ProgrammingError:
    print 'my_curs is closed;',
if my_conn.open:
    print 'my_conn is open'
else:
    print 'my_conn is closed'

notez que with closing(arg_obj) n'appellera pas les méthodes __enter__ et __exit__ de l'objet argument; il appellera seulement la méthode close de l'objet argument à la fin du bloc with . (Voir dans cette action, il suffit de définir une classe Foo avec __enter__ , __exit__ , et close méthodes contenant des déclarations simples print , et de comparer ce qui se passe quand vous faites with Foo(): pass à ce qui se passe quand vous faites with closing(Foo()): pass .) Cela a deux conséquences importantes:

tout d'abord, si le mode autocommit est activé, MySQLdb va BEGIN une transaction explicite sur le serveur lorsque vous utilisez with connection et commit ou roll la transaction à la fin du bloc. Ce sont des comportements par défaut de MySQLdb, destinés à vous protéger du comportement par défaut de MySQL de commettre immédiatement toutes les déclarations DML. MySQLdb suppose que lorsque vous utilisez un gestionnaire de contexte, vous voulez une transaction, et utilise le BEGIN explicite pour contourner le paramètre autocommit sur le serveur. Si vous êtes habitué à utiliser with connection , vous pourriez penser autocommit est désactivé alors qu'en fait il était seulement contourné. Vous pourriez avoir une surprise désagréable si vous ajoutez closing à votre code et perdez l'intégrité transactionnelle; vous ne serez pas en mesure de faire reculer les changements, vous pouvez commencer à voir des bogues de concurrence et il peut ne pas être immédiatement évident pourquoi.

le Second, with closing(MySQLdb.connect(user, pass)) as VAR lie objet de connexion à VAR , contrairement à with MySQLdb.connect(user, pass) as VAR , qui lie un nouveau curseur de l'objet à VAR . Dans ce dernier cas, vous n'auriez pas d'accès direct au objet de connexion! Vous devriez plutôt utiliser l'attribut connection du curseur, qui fournit un accès par procuration à la connexion originale. Lorsque le curseur est fermé, son attribut connection est défini à None . Il en résulte une connexion abandonnée qui restera dans les parages jusqu'à ce que l'un des événements suivants se produise:

• toutes les références au curseur sont supprimées
• le curseur sort du champ d'application
• Le temps de connexion à
• la connexion se ferme manuellement via les outils d'administration du serveur

vous pouvez le tester en contrôlant les connexions ouvertes (dans Workbench ou par en utilisant SHOW PROCESSLIST ) tout en exécutant les lignes suivantes une par une:

with MySQLdb.connect(...) as my_curs:
    pass
my_curs.close()
my_curs.connection          # None
my_curs.connection.close()  # throws AttributeError, but connection still open
del my_curs                 # connection will close here