On May 6, 2008, at 12:14 PM, Laurence Rowe wrote:
Martijn Faassen wrote:
One thing I understood from Christian Theune is that with scoped
sessions, explicit session.save() is not always necessary. Since I
see it being used here, could you perhaps comment on this?
Registering a mapper with
On May 6, 2008, at 5:24 PM, Martijn Faassen wrote:
Hey Michael,
Thanks for the input!
Michael Bayer wrote:
[snip]
So I've already not liked save_on_init for a couple of years due to
its inherent intrusiveness, and because SA historically does not
like being in the business of prov
On May 7, 2008, at 7:08 AM, Martijn Faassen wrote:
Hi there (especially Christian),
I think we can work with explicits saves. In many cases the user
won't have to worry about it anyway as the container object will do
it for them (besides making the relation), or this 'query container'
we
On May 7, 2008, at 1:29 PM, Laurence Rowe wrote:
I'm thinking more about having the same classes mapped to different
databases at different points in the application. Imagine a
departmental address book app. Intstances of the departmental
address book are created for each department, each
On May 7, 2008, at 2:29 PM, Laurence Rowe wrote:
When the generic address book application is built you don't know
what the departments will be called or indeed how many departments
there are. An address book is not be a great example, but I know of
intranet portal sites where this is a re
On May 28, 2008, at 7:09 PM, Laurence Rowe wrote:
Engine configuration is a subset of session configuration. You
cannot have a single ScopedSession for a package if you want to have
multiple instances of that application. We must work with unbound
metadata if we have this goal. That impl
On May 30, 2008, at 9:44 AM, Martijn Faassen wrote:
Hey,
Michael Bayer wrote:
[snip discussion on BoundMetadata I don't comprehend yet but
probably should :)]
As far as ScopedSession, it's really just a thread local variable.
Like any global threadlocal, you can stick wh
session, I tried to use the following
pattern
(many thanks to Michael Bayer, btw.):
database module ---
SASession = scoped_session(sessionmaker(
transactional = True,
autoflush = True,
extension = ZopeTransactionExtension()))
def getSASession():
SASession.remove
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
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
On Jul 19, 2008, at 6:33 AM, Martijn Faassen wrote:
Laurence Rowe wrote:
This is now fixed in trunk. For the moment I'm depending on
SQLAlchemy trunk for the new after_attach hook until beta3 is
released.
Maybe it's time to start depending on 0.5?
No problem with that from my side, thoug
On Jul 19, 2008, at 10:29 AM, Brandon Craig Rhodes wrote:
Laurence Rowe <[EMAIL PROTECTED]> writes:
This is now fixed in trunk. For the moment I'm depending on
SQLAlchemy
trunk for the new after_attach hook until beta3 is released.
Could the fix be backported and a new release made? I ha
i should be doing 0.4.7 and 0.5beta3 early this week. both include
"after_attach()".
On Jul 21, 2008, at 4:45 AM, Martijn Faassen wrote:
Hey,
On Mon, Jul 21, 2008 at 9:55 AM, Malthe Borch <[EMAIL PROTECTED]>
wrote:
Martijn Faassen wrote:
Thanks for the offer. I think this is up to La
13 matches
Mail list logo
