On Tue, Jun 17, 2008 at 11:52:49AM +0200, Martijn Faassen wrote:
>> However, Laurence's point about database re-connection is relevant here.
>> If the Session were looked up by an interface, someone could implement
>> seamless database re-connection (lots of complex code) without polluting
> And what is seamless database re-connection and why is this a job for Zope
> and not for SQLAlchemy?
I mean in the situation where you change the database connection
parameters on an existing connection and don't want to restart zope to
use the new connection parameters.
Why people seem to want the above escapes me, but people do seem to want
I totally agree that Zope should not be responsible for re-connecting on
>>> where 'Session' is a custom SA scoped session.
>>> I've checked in my (documented) experiment in here:
>>> The interesting bits are here:
>> This looks very nice. I'm not sure IDatabase.engine is necessary, it
>> seems to be only used internally to Database.
> Yes, but it is policy someone may want to change. In this case I
> implemented the policy to look up the engine by name, but it might be the
> default policy would be to simply look up IEngine locally or something.
Just commenting that IDatabase.engine is not used by any code external
to the Database object. There's no use case for it to be public.
>> Also, any view code should really be getting the connection directly from
>> the session.
> I don't understand that what you mean by 'connection'. Oh, you mean which
> engine is used? That's really just some testing code, I imagine it could
> directly manipulate the session in realer code.
I was more thinking if you wanted to execute raw sql from a view class
you would do that via the engine. But it seems that the session has an
execute() method for that.
>> As Laurence has suggested, the session persists, so
>> IDatabase.configuration will only be called once per thread. Not sure if
>> creating one new engine per thread is bad.
> I don't know either. I've assumed that one wouldn't want to recreate the
> engine for each thread, but perhaps that's fine and we don't break any,
> say, connection pooling mechanisms that way? I do not know.
Unfortunately I don't either...
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -