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
created
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
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 in
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
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 th
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 -
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 Brian,
I've updated the code in svn to be in synch with our latest insights
concerning what IDatabase should look like.
Looks like the next area of interest for at least my use case will be a
way to set up engines. I'm one of those people that would at least like
to offer the option to c
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 the
On Tue, Jun 17, 2008 at 06:05:10PM +0200, Martijn Faassen wrote:
> 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
>>
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 would be different.
For this to be effi
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 different
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 per-threa
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(IDa
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 03:52:51PM +0200, Martijn Faassen wrote:
> Hi there,
>
> Just as some context: I'm not proposing to extend zope.sqlalchemy at
> all.
I was;)
> I'm proposing to write an extension that has the configuration
> pattern I sketched out. I also don't intend to write the last
>
Laurence Rowe wrote:
[snip]
Why not just have:
class IDatabase(Interface):
"""A utility that specifies the database.
"""
def session_factory():
"""Create a new session
"""
def id():
"""Get unique id for this database configuration.
This should b
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
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 come
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
> suc
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
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
>> zope.
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 trade-off
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 keep
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
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 (appl
26 matches
Mail list logo