Michael Bayer wrote:
>
>Jonathan LaCour wrote:
>>
>> metadata = MetaData()
>> engine = create_engine('connection_string')
>> metadata.connect(engine)
I like this API suggestion--it's simple, clear, flexible, and above all
explicit.
>>
>> 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?
>>
>
> Hey list, are you confused by the current system ? Please let me know.
I have to say that the first time I tried to use one of the *MetaData variants
I was very confused and took quite a bit of time to read about the different
options before I was able to make a decision as to what was best for my
situation.
The API suggested by Jonathan seems very clear. I would add an optional
"threadlocal=True/False" argument to both the create_engine() function (I guess
it's already there with strategy="threadlocal") and the MetaData() constructor.
That should handle both of the current threadlocal options and it's absolutely
clear where it applies (in the engine or in the metadata).
I think one of the reasons there hasn't been much feedback up to this point is
that the current API does handle most use cases despite being a bit confusing.
>
> 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
> "connect_threadlocal()" or something like that for people who want
> that behavior. i would like to have just one object that does the
> whole thing, now that some of the early FUD has subsided.
That sounds reasonable, I would vote for BoundMetaData and DynamicMetaData to
be deprecated eventually.
~ Daniel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
