On Mar 13, 2007, at 4:26 PM, Jonathan LaCour wrote:
Michael Bayer wrote:
the only change I would favor here would be to merge connect into
MetaData, BoundMetaData and DynamicMetaData stay around for backwards
compat for probably forever, and perhaps we add another method called
Michael Bayer wrote:
OK, let me tell you what just happened the other day. Im dealing
with a Pylons application, and Pylons provides the SA engine by
binding it to the Session. but the application also had a
DynamicMetaData stuck in there, and at some point they were creating
their own
On Mar 21, 2007, at 3:55 PM, Jonathan LaCour wrote:
I see your point. I don't care what you do with DynamicMetaData, as
long as I can do this one day:
metadata = MetaData()
engine = create_engine(...)
metadata.connect(engine)
... preferably soon ;)
right..but just my
Hey list, are you confused by the current system ? Please let me know.
the only change I would favor here would be to merge connect into
MetaData, BoundMetaData and DynamicMetaData stay around for backwards
compat for probably forever.
Not actually confused by the system. Since I need to
I think its more
confusing for the API to break backwards-compatibility every 5 or 6
releases.
Also i think adding a whole new class DelayedMetaData,
which is literally just to avoid passing a flag, well i wont say
insane but its a little obsessive.
Agreed here.
Hey list, are you
can I have some feedback from the list who is using the thread-local
capability of DynamicMetaData, and/or are using global_connect() ?
(another feature i didnt like but it was me bowing to early pressure
from TG users).
Probably this will be no surprise, since I contributed most of the
On Mar 13, 11:59 am, Gaetan de Menten [EMAIL PROTECTED] wrote:
I only discovered (or at least understood) this thread localness
of DynamicMetaData, and honestly, I don't understand in what case
it can be useful. It seems like the thread localness is limited
to the engine connected to
On 3/14/07, JP [EMAIL PROTECTED] wrote:
On Mar 13, 11:59 am, Gaetan de Menten [EMAIL PROTECTED] wrote:
I only discovered (or at least understood) this thread localness of
DynamicMetaData, and honestly, I don't understand in what case it can
be useful. It seems like the thread localness is
[...] I couldn't use BoundMetaData because I don't know the
connection parameters until much after import time, so I am using the
only other option I know of, which is DynamicMetaData [...].
I have exactly the same problem. One option is to use global_connect and
default_metadata (doc:
I only discovered (or at least understood) this thread localness of
DynamicMetaData, and honestly, I don't understand in what case it can
be useful. It seems like the thread localness is limited to the engine
connected to the metadata. So what I'd like to understand is when
anyone wouldn't want
Michael Bayer wrote:
My controller actions don't worry about transactions or connections
at all, they just execute insert/update/delete/select actions and if
an exception is raised, their work is rolled back automatically.
well, thats exactly the pattern provided by strategy=threadlocal,
What do you think?
Hey list, are you confused by the current system ? Please let me
know.
the only change I would favor here would be to merge connect into
MetaData, BoundMetaData and DynamicMetaData stay around for
backwards compat for probably forever, and perhaps we add another
Er well the whole point of DynamicMetaData was to replace the old
ProxyEngine, which was intended to emulate SQLObject's i dont know
what its called object which is what TG was using for thread-local
context.
Also, it doesnt entirely make sense that the threadlocal engine
strategy would
13 matches
Mail list logo
