SQLAlchemy et kinterbasdb dans des applications distinctes sous mod_wsgi

Question

J'essaie de développer une application en utilisant turbogears et sqlalchemy. Il existe déjà une application existante utilisant kinterbasdb directement sous mod_wsgi sur le même serveur. Lorsque les deux applications sont utilisées, aucune des deux ne semble reconnaître que kinterbasdb est déjà initialisé Y a-t-il quelque chose d'évident qui manque à propos de l'utilisation de sqlalchemy et de kinterbasdb dans des applications distinctes? Afin de s'assurer qu'une seule instance de kinterbasdb est initialisée et que les deux applications utilisent cette instance, est-ce que quelqu'un a des suggestions?

Answer 1

Je pensais que je déjà posté ma solution ...

Modifier les applications pour fonctionner sous WSGIApplicationGroup $ {GLOBAL} dans leur fichier httpd conf et patcher sqlalchemy.databases.firebird.py pour vérifier si self.dbapi .initialized est vrai avant d'appeler self.dbapi.init (... était la seule façon que je pouvais gérer pour obtenir ce scénario opérationnel
le patch 0.4.7 SQLAlchemy.

 
diff -Naur SQLAlchemy-0.4.7/lib/sqlalchemy/databases/firebird.py SQLAlchemy-0.4.7.new/lib/sqlalchemy/databases/firebird.py 
--- SQLAlchemy-0.4.7/lib/sqlalchemy/databases/firebird.py  2008-07-26 12:43:52.000000000 -0400 
+++ SQLAlchemy-0.4.7.new/lib/sqlalchemy/databases/firebird.py 2008-10-01 10:51:22.000000000 -0400 
@@ -291,7 +291,8 @@ 
     global _initialized_kb 
     if not _initialized_kb and self.dbapi is not None: 
      _initialized_kb = True 
-   self.dbapi.init(type_conv=type_conv, concurrency_level=concurrency_level) 
+   if not self.dbapi.initialized: 
+    self.dbapi.init(type_conv=type_conv, concurrency_level=concurrency_level) 
     return ([], opts) 

    def create_execution_context(self, *args, **kwargs):