Martin Aspeli wrote:
[snip]
Why can't it just be
getUtility(ISession)
?
Because the internals won't let you. As I said in my reply, a Session is
not quite like a local utility. Trying to pigeonhole it that way isn't
easy. It'd need some clever component wizardry to make sessions be
Brian Sutherland wrote:
On Mon, Jun 16, 2008 at 08:40:24PM +0200, Martijn Faassen wrote:
Hi there,
In some earlier discussions a number of approaches to integrate SQLAlchemy
into Zope were discussed. Following up on that, I've tried a particular
approach that tries to use ScopedSessions with
Brian Sutherland wrote:
On Mon, Jun 16, 2008 at 08:40:24PM +0200, Martijn Faassen wrote:
[snip]
from z3c.sa_integration import Session
...
def somewhere_in_a_view(self):
session = Session()
return session.query(Test).all()
For some reason this raises a warning bell in my head. I
Martin Aspeli wrote:
Brian Sutherland wrote:
[snip]
For some reason this raises a warning bell in my head. I keep on
thinking: this is zope, the session is a classic case for a utility, we
should be getting it in views by an interface.
FWIW, I had the same though.
I think there's a
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
Hi there,
On Tue, Jun 17, 2008 at 2:30 PM, Brian Sutherland
[EMAIL PROTECTED] wrote:
[snip]
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.
While I am not sure we have a strong use case for engine anyway, I
On Tue, Jun 17, 2008 at 11:58:56AM +0200, Martijn Faassen wrote:
Anyway, the balance can come out somewhere else. People are free to write
their own integration approaches, it's just that mine is actually about
trying to make exactly this pattern work in the first place. Then when I
Hi there,
Just as some context: I'm not proposing to extend zope.sqlalchemy at
all. I'm proposing to write an extension that has the configuration
pattern I sketched out. I also don't intend to write the last
SQLAlchemy integration layer; I wouldn't be so presumptious. :) That
said, if we can
Martijn Faassen wrote:
Hi there,
On Tue, Jun 17, 2008 at 2:30 PM, Brian Sutherland
[EMAIL PROTECTED] wrote:
[snip]
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.
While I am not sure we have a strong use
Hey Laurence,
Laurence Rowe wrote:
[snip]
I'm not sure connection pooling is really useful in a threaded
environment with recycled sessions. You want n threads = n connections.
If we started creating new sessions each request then things would be
different.
Mike Bayer says the following:
On Tue, Jun 17, 2008 at 05:25:56PM +0200, Brian Sutherland wrote:
class IDatabase(Interface):
def scopefunc():
The scopefunc
def session_factory():
The session factory
def scopefunc():
util = component.getUtility(IDatabase)
return
Brian Sutherland wrote:
[snip]
This would probably be close to what I would write for my usecase:
class Database:
implements(IDatabase)
def __init__(self, *args, **kw):
self._args = args
self._kw = kw
def scopefunc(self):
return None # use default
Hey,
[replying to myself]
Martijn Faassen wrote:
Laurence Rowe wrote:
[snip]
I'm not sure connection pooling is really useful in a threaded
environment with recycled sessions. You want n threads = n
connections. If we started creating new sessions each request then
things would be
2008/6/17 Michael Bayer [EMAIL PROTECTED]:
On Jun 17, 2008, at 10:09 AM, Laurence Rowe wrote:
I'm not sure connection pooling is really useful in a threaded environment
with recycled sessions. You want n threads = n connections. If we started
creating new sessions each request then things
On Jun 17, 2008, at 12:41 PM, Laurence Rowe wrote:
What connection pooling is used by default? e.g. with
create_engine('sqlite:///:memory:')
sqlite is a special case, it uses the SingletonThreadPool. This pool
holds onto one connection per thread.This is used in SQLite
because of a
Hey,
Michael Bayer wrote:
[snip comments on connection pooling]
Thanks for showing up here and participating in the discussion, Michael.
To me it's clear we should try to reuse engines as much as we can.
Regards,
Martijn
___
Zope-Dev maillist -
Martijn Faassen wrote:
Martin Aspeli wrote:
Brian Sutherland wrote:
[snip]
For some reason this raises a warning bell in my head. I keep on
thinking: this is zope, the session is a classic case for a utility, we
should be getting it in views by an interface.
FWIW, I had the same though.
I
Martin Aspeli wrote:
Martijn Faassen wrote:
Martin Aspeli wrote:
Brian Sutherland wrote:
[snip]
For some reason this raises a warning bell in my head. I keep on
thinking: this is zope, the session is a classic case for a utility, we
should be getting it in views by an interface.
FWIW, I had
Laurence Rowe wrote:
Martin Aspeli wrote:
Martijn Faassen wrote:
Martin Aspeli wrote:
Brian Sutherland wrote:
[snip]
For some reason this raises a warning bell in my head. I keep on
thinking: this is zope, the session is a classic case for a utility, we
should be getting it in views by an
Martin Aspeli wrote:
Martijn Faassen wrote:
[snip]
The Zope component architecture is not about seeing explicit calls
into it everywhere. That's not the point of it. The point of it is
about making applications more flexible by allowing people to plug in
components. My approach allows you to
Martijn Faassen wrote:
Hi there,
In some earlier discussions a number of approaches to integrate
SQLAlchemy into Zope were discussed. Following up on that, I've tried a
particular approach that tries to use ScopedSessions with a custom scope
that isn't just per thread, but also per site
21 matches
Mail list logo
