On Fri, Mar 13, 2009 at 12:26 AM, Adrian Holovaty <[email protected]>wrote:
> > On Thu, Mar 12, 2009 at 11:53 PM, Alex Gaynor <[email protected]> > wrote: > > Great, since we've moved so quickly on improving our plumbing for this > there > > was one other idea I wanted to put forth(since I believe it needs to > happen > > for any multidb implementation). In terms of plumbing the cornerstone of > my > > multidb proposal is the addition of a django.db.connections object which > > lazily returns connections by subscripting based on a DATABASES option > which > > is a dictionary of dictionaries. I think we could add support for this > > relatively easily, with full backwards compatibility. However, we only > have > > 1 week until feature freeze so I wouldn't want to proceed with this > unless > > everyone was completely comfortable with that proposed API, but I figured > > I'd bring it up since we have moved so quickly on these past bits. > > Yeah, a collection of connections (called django.db.connections or > whatever) is one of the next logical steps for multi-database support. > But for the time being, that's 90% just a pretty API and only 10% > plumbing. It can be worked-around completely without changing Django > internals. (I've got a DATABASES setting in my application, along with > a custom manager that checks the setting to get connection-specific > parameters -- code very similar to > http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/ > ) > > Regarding the one-week-until-feature-freeze reality -- we haven't > *hit* the feature freeze yet, so it seems like it's still fair game, > but this *would* be a bigger change than the previous few, so it'd be > worth discussing the pluses and minuses. > > A bigger issue (one that requires plumbing, unless I'm completely > missing something) is to get django/db/transaction.py to be aware of > the multiple connections. All of the functions in there deal directly > with the global connection, and I don't immediately see an easy way to > refactor things to work on separate connections. Any ideas? Alex, have > you addressed this in the Grand Proposal of yours? :-) > > Adrian > > > > My "nuts and bolts" document(which I've alluded to several times but haven't actually posted since my laptop has been dead :( ) has fixing up the transcation stuff, specifically I put it after we had a basic public API, but before we get into the more complicated bits in terms of the implementation schedule. That being said it looks like all the states there is handled in a series of dictionaries keyed on thread id, so my instinct would be to turn those into dictionaries of dictionaries keyed on thread id and connection alias respectively and have each of the relevant functions take an extra parameter, which defaults to None, which should be a list of db aliases that the op should be preformed on(None indicicating all dbs), this preserves backwards compatibility and makes sense in terms of the common usage, for example at the end of a request I want to commit against all dbs but when I create a savepoint I only actually create that on 1 db. Having said all that I don't think that's stuff that necessarily needs to happen when we add the connections object, since as it is our transaction stuff doesn't come into play when someone grabs a cursor themselves with even our single DB(this is filed as a bug and I imagine will get fixed for 1.1). If no one has any seroius objections other than it's a sort of big addition with not a ton of time and we don't want to mess of the public/private API bridge I'll probably start coding something up tommorow. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
