On Sat, Apr 25, 2009 at 2:01 AM, Russell Keith-Magee <freakboy3...@gmail.com > wrote:
> > On Wed, Apr 22, 2009 at 1:45 AM, Alex Gaynor <alex.gay...@gmail.com> > wrote: > > Hello All, > > > > As you know by now I've been selected to work on multiple database > support > > in Django as a part of the Google Summer of Code. I'm going to try to > keep > > this brief as a) not much of my API thoughts have changed since my > original > > proposal, and b) Django 1.1 is getting ready to leave the factory so > bogging > > down this list with design decisions now seems like an exceptionally bad > > idea. > > In the interim, some food for thought: > > There are a number of places where the design you have proposed > differs from the design Simon proposed in his post DjangoCon email > [1], and I haven't found (or have overlooked) subsequent discussions > where this basic design proposal was changed. A cursory glance reveals > at least two - the handling of database names/aliases, and your > DatabaseManager vs Simon's interface methods on the base Manager > object: > > [1] > http://groups.google.com/group/django-developers/browse_thread/thread/9f0353fe0682b73 > > When the community is ready for design discussions to recommence, you > would be well served to be able to explain and defend the differences > between Simon's proposal and your own. > Both reasons are actually really simple: Simon uses a new DSN based syntax for specifying DBs, however I find this pretty akward in the presence of our existing way for defining DB settings. Further a DSN method removes the presence of something like DATABASE_OPTIONS(unless we start adding query strings onto the end), which is very useful for things like the postgresql auto commit option, plus I plan to move the TEST_DATABSE_* settings into DATABASE_OPTIONS, since things like charset are DB dependent. My reason for not putting the "DBManager" on models.Manager is that it makes the implementation hugely awkward. The purpose of a DBManager construct is to defer selecting the connection until all the details of the query are known, so you can make a decision programmatically. By contrast, a Manager exists exclusively at the first stage of the QuerySet. The only way programatically for this to work is for the Query object to keep a reference to the Manager/Manager.get_connection which strikes me as bad design. > > >The original proposal is here[1], and as I've said I have no changes > > in API thoughts since then, however I still want to hear any feedback > people > > have for that. The other open issue is how to handle switching database > > backends in use when you have a partially created connection object, > there's > > 3 major ideas as to how to do that that I've seen: > > Malcolm's analysis here is fairly comprehensive; I don't have much to > add to what he has said. > Indeed, Malcolm gets huge thanks for taking all the time to look at this and comment, he's not mentoring this project and even is mentoring a seperate one but he clearly took a lot of time to carefully consider this. > > Russ %-) > > > > 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 django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
