ab wrote: > For the api to accept a DSN, alias, or connection anywhere would add > similar code in multiple places. I propose that the aliases are mapped > into django.db.connections. For your example, you could use > django.db.connections.archive. I also propose that you can either > define a single database (as now) or multiple DATABASES (as you > propose) and to define both or neither is an error. But anyways, how > to name/specify a database is semi-bikesheddy and orthogonal to the > issue of how to actually choose the database to be used, which is the > more important one. Here's my take on that: > > My biggest problem with Simon's original proposal is that the > connection-choosing logic is too spread out. Sticking stuff on your > Model classes makes sense when the code is "local to that model" -- > like methods, metadata, or choosing a connection per-table -- but that > doesn't make sense for a lot of multi-db setups. For complicated stuff > like sharding, I think you'd want all the logic in the same place. > > Counter-proposal: > A *project-global* get_connection function, maybe in a location > specified by settings. > Input: the queryset, at least, and probably whatever else you'll > likely want to use: the model class, tables joined with, > fields_accessed?, etc. > Output: a connection object
I personally think we need an approach where we provide the framework that can support sharding and master/slave database layouts, but where that's not directly built in, since as these discussions seem to show, everyone has a different need... A function whacked in settings might work best, especially if there's ones shipped with Django to do the simpler stuff (like databases set per-model, something one of the projects I was on was considering, even though it's very simple); as long as it has access to some kind of state, it can also then decide that a user was saved in the last second, and you need to use the master, or something of the sort. Having features where you put attributes or functions on models or apps can then be provided by something Django ships with that implements said scanning of models or apps (I'm pretty sure this is possible, if we managed to deliver all the appropriate arguments to the function...). This way, most people will be satisfied by the shipped functions (which are somewhat analogous to generic views, in a very very roundabout way) and people who Love Control™ can roll their own. Just my two cents. I'll scuttle back to migrations libraries now. Andrew --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
