On Mar 13, 2007, at 2:46 PM, Jonathan LaCour wrote:
>> >> 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. both the turbogears and the pylons communities demanded this feature almost immediately, for this reason...they want to write an application that runs multiple instances at once. I think this is a requirement of the WSGI spec, its why TG had all this angst with CherryPy until version 3 somehow fixed it, its this whole shebang that everyone wanted. not like id ever run my apps that way, id just run them separate. > > 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: > the point of MetaData was to address the other widespread early critque of SA, that "you cant create SQL constructs without connecting to a database". People were coming to me and arguing that I should drop the the entire SQL construction system and use sqlobject2 for this reason. So now you have MetaData. While the API might be a slight bit verbose, its hardly any big deal and its a little late to keep mixing things up just for subtle aethetic reasons..maybe as a version 0.4 thing, but I dont see this as such a big/urgent deal. also i dont see how "threadlocal=False" is *that* tragic of an API. I know you think its insane, but I think a lot of people are using it in this manner. 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). > > 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 :) I think it would be nice enough to have just MetaData with a pluggable strategy or something, but the API that exists was to make it unavoidably clear the difference between a MetaData that just holds tables versus one that can propigate an engine. anyway, I dont think people are very confused at all. we've been around for over 18 months and this is the first time anyone has had an issue with DynamicMetaData. There was plenty of time in between 0.1 and 0.2 for people to review, we had tons of email threads about the design of 0.2, everyone seemed happy. 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. > > 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
