Michael Bayer wrote:
> 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.
Okay, so basically it works the way it does because it was created as
an equivalent for something in SQLObject. Fair enough, I suppose, but
I am still struggling to identify the "correct" way to do things...
> Also, it doesnt entirely make sense that the "threadlocal" engine
> strategy would conflict with dynamicmetadata's thread local-ness.
> if you have one engine per thread, and that engine is on the tlocal
> strategy, it should still be doing its thing within the one thread
> that its used within. so feel free to try to reproduce that in a
> ticket or something.
Well, its not so much that they _conflict_ (bad choice of words on
my part), but that I did not expect DynamicMetaData to behave in a
threadlocal way, which caused me problems. Once I disable this aspect
of DynamicMetaData, everything worked just fine.
> but also, the "threadlocal" engine strategy is the thing here thats
> kind of like, "you probably dont need to be using it"...its basically
> SA 0.1's built in behavior kind of ripped out and put over to the
> side, where people that really want that sort of thing can use it. but
> ive downplayed it a lot since then, since its kind a confusing feature
> if youre not the person who wrote it (or read/understood the entire
> source to it).
Well, I am not married to using it at all. If its a sort of unsupported
or not recommended way of doing things, I would love to see a
Deprecation Error thrown into SQLAlchemy, and I'd also like to hear the
recommended pattern that I can use in its place.
Currently, I am creating a non-threadlocal DynamicMetaData (only so that
I can delay the setup of the engine) and a TLEngine. The metadata is
utilized from many threads, because all of the tables in my model are
defined on that metadata, and are used throughout my application.
This approach gives me a convenient way to manage connections and
transactions in my WSGI application at a fairly high level. In my main
HTTP dispatcher, I can essentially do this:
try:
start()
...
# lookup a controller action by URL map
...
# call the method and get the response
...
commit()
except:
rollback()
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.
I have defined the start/commit/rollback methods as convenience
functions that can be imported anywhere, and basically call the
begin/commit/rollback methods on metadata.engine.
Can I do this without using the threadlocal strategy? What is the
pattern that you would recommend instead?
> whereas DynamicMetaData i think is in pretty wide usage as a thread
> local construct and its pretty straightfoward. the non-threadlocal use
> case for it is not as obvious to me.
I must still not understand the appropriate usage pattern for
DynamicMetaData. 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. The fact that it
provides threadlocal behavior only caused me a headache, because I would
get errors unless it was disabled.
Thanks for the guidance, I am sure that there is a better way of going
about this, but I certainly couldn't figure it out.
--
Jonathan LaCour
http://cleverdevil.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
