> > 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 > 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. > > but I need to get at least 20 or 30 users on this list telling me > how they are using metadata. i am not doing a plain web app (although it will have http interface and behave like web app in some ways - but this is just _another_ remote UI), so i dont really know the difference of current *MetaData's. Even if well documented, the usage of these will go deep in the infrastructure and hence be forgotten and stay hidden - its not everyone's business to create db connections and alike.
And for this, having 2 different strategies, which differ in some _hidden_ ways, and which usage is always invisible... i vote for having one type of object - or one factory if u want - with parameters. Only who should know about diffs would have to. so far i have only noted that certain cases work with premade BoundMetaData() and break with plain MetaData() being later bound. i can try dig them out if u want. btw theoreticaly, can u have a XXXMetadata obj that is used, closed and later turns into YYYMetaData? i can see a use case for this and it would not be easy possible with current system. In the new variant one can keep forever the metadata as made once, and just change the way it is connected, then disconnected. Hey, is this a sort of usageContext() ? i.e. u have a MetaData(), which .connect(args-here) returns some context-like object which hides the exact implemetation, and when dropped will close connection. ciao svilen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
