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",
> and its clear that you understand how it works, so there is no problem
> at all doing that. its merely a pattern that allows a little less
> explicitness (i.e. more magic).
Ah, okay, so I am not missing anything here, just appreciating this
particular piece of magic :)
> people were quite confused by it when it was the built-in behavior,
> which is because a lot of people dont really understand what
> "threadlocal" means. so i made it all optional. no need to deprecate
> it though, its still useful stuff.
I am surprised that people don't know what "threadlocal" means, since
it seems like a threaded application with a database pool is probably
one of the most familiar ways to do things. But, still, if people were
emailing the list in confusion, thats got to mean something :)
>> 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.
>
> the main use case for DynamicMetaData is a single application, usually
> a web application, that is actually many instances of the same
> application running at once and talking to different databases for
> each instance. so on each request, the DynamicMetaData gets pointed to
> the official database connection for that request, within that thread.
Wow, does this ever actually happen? It seems like a very obscure use
case to me.
> You are free to use it the way youre using it too. if i were writing
> the app that didnt know the connection parameters until later, i
> might just put my entire "create the Tables + mappers" logic within a
> function call that gets called when we do know the actual connection
> string...
... eek!
> but then again using DMD with threadlocal turned off is yeah a lot
> easier and cleaner since you can keep your declarations at the module
> level.
Yes, this is a lot cleaner, however its confusing. Personally, I
think that there should be one and only one MetaData class that can be
told how to act. As far as I can tell, you could replace the existing
options in SQLAlchemy (BoundMetaData, DynamicMetaData) and simplify
things a bunch in the process:
metadata = MetaData()
engine = create_engine('connection_string')
metadata.connect(engine)
This would let you get rid of BoundMetaData and DynamicMetaData and just
have one simple, easy way to do things. Plus, it would give you the
ability to do what I am using DynamicMetaData to do without having to
pass in a weird threadlocal=False kwarg.
For people who want the insane threadlocal behavior of DynamicMetaData,
you could have the MetaData object take in the same kwarg which would be
defaulted to the saner False option (unlike the current DynamicMetaData)
metadata = MetaData(threadlocal=True)
...
I think that this would be a lot less confusing for users. I would
be more than willing to work on a patch to make this happen if you
like the idea. If not, I will at least supply a patch for yet another
MetaData subclass called DelayedMetaData that gives you the behavior of
DynamicMetaData without the threadlocal insanity :)
What do you think?
--
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
-~----------~----~----~----~------~----~------~--~---
