On Sep 30, 2008, at 2:46 PM, Michael Shaw wrote:

>
> I am working on two projects that are bothing running under mod_wsgi.
> The first is using kinterbasdb directly (no sqlalchemy).
> The second is using sqlalchemy.
> Problem arises when one or the other attempts to call kinterbasdb.init
> after the other one has already done so.
> My question is this:
> When sqlalchemy attempts to initialize kinterbasdb, it appears to be
> calling it with:
> def create_connect_args(self, url):
> ...
> 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 kinterbasdb has already been intialized this is supposed to
> immediately throw a ProgrammingError.
> But the programming error is getting thrown when it attempts
> _k.concurrency_level_set(concurrency_level)
>
> Could importing kinterbasdb inside databases.firebird.py and referring
> to it as dbapi during the call to init be causing this?  Anyone with
> more experience able to express this better?

its not that the module is called "dbapi", its just that the  
firebird.py dialect is assuming that its own _initialized_kb variable  
holds the state of whether or not init() has been called.    A better  
approach would be if the firebird DBAPI could be queried for whether  
or not it's legal to call init().   If catching the ProgrammingError  
is the only option, that might be needed within the firebird dialect.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to