On Fri, Dec 18, 2009 at 12:41 PM, Brett Hoerner <[email protected]> wrote: > I'm not sure if 1.2 intended to fully support read-slaves, but I'll > post this quick anyway as we've just run into it while trying to > upgrade at DISQUS. > > You might think that having support for multiple databases implies > that using a read-slave would Just Work, and that's mostly true. > There's one edge case I've run into when you try to relate objects > using instances created from different mirrors of the same database. > Because of the checks against instance._state.db you can't select an > object from a read-slave and assign it to a foreign key relation (and > probably other relations) on the master, even though you know this is > a mirror and not a different database. > > Here's a quick code example: http://dpaste.org/Bozd/ > > The only solution I've thought of (and I haven't thought long, I just > ran into this) is another database setting where you could tell Django > that this DB is a mirror of another (by name?) so that > instance._state.db on a read-slave created object actually holds the > value of DATABASES['that_read_slave']['mirror_of'] (or whatever key). > In other words a User selected from 'read_slave' might actually have a > user_instance._state.db value of 'default', because that's it's true > home, and any relations should be compared to that. > > I would think read-slaves would be a pretty common application of > multidb, but I can only speak to our use case. I know it's a bit late > in the game, but we'll have to work up our own local fix or go with a > proper one before we can deploy 1.2. And to think I was so happy > about how many local Django patches I was able to remove going from > 1.0->1.2. ;) > > Amazing work, Alex & Russell, many thanks. > > Regards, > Brett > > > > On Dec 17, 11:43 pm, Russell Keith-Magee <[email protected]> > wrote: >> Hi all, >> >> This is a second and final call for feedback on the multidb branch. >> >> Barring any objections or the discovery of major problems, my >> intention is to commit this early next week, hitting the alpha 1 >> feature deadline by the skin of our collective teeth :-) >> >> There has been one big change since the last call for feedback - >> thanks to Justin Bronn, GIS is now fully multi-db compliant. >> >> There have also been a couple of small changes - mostly integrating >> the contrib applications with multidb features. For example, the >> contenttypes app now maintains a cache of content type objects that is >> multi-db aware. >> >> The only really visible change is a new 'db_manager()' operator on >> Managers. This is used to obtain a Manager instance that is bound to a >> specific database. This is required because: >> >> Author.objects.using('foo') >> >> will return a QuerySet that is bound to foo - however, methods like >> User.objects.create_user(...) and >> Permission.objects.get_by_natural_key(...) are on the Manager, not the >> QuerySet. >> >> So, you can now call: >> >> Author.objects.db_manager('foo') >> >> which will return a Manager (Author's default manager) that is bound >> to the foo databse. Subsequent calls to using() can change this >> binding if necessary. >> >> At the last call for feedback, questions were raised about admin >> support. I've done some investigation, and it turns out that you can >> write ModelAdmin definitions that bind a model to a different >> database. I'm in the process of documenting the exact steps that are >> required. Coming up with a pretty integration layer with admin will be >> left for Django 1.3, when we will be addressing the issue of how to >> provide a good public interface to multidb for common use cases >> (master/slave, sharding, etc) >> >> As always, the code is available in the multi-db SVN branch: >> >> http://code.djangoproject.com/svn/django/branches/soc2009/multidb/ >> >> or from Alex's github branch: >> >> http://github.com/alex/django/tree/multiple-db >> >> Again, any and all feedback welcome. >> >> Yours, >> Russ Magee %-) > > -- > > 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. > > >
Thanks for the feedback Brett (sorry I didn't get back to your original email). I think you're right that this is an important usecase, any case where identical pks indicate mirroring across different DBs this will fail. I'm wondering if perhaps the most prudent thing to do would be to simply remove this check. The end result will be you'll get an integrity error on Postgres/Oracle when you try to save (and SQLite and MySQL will just let you do whatever). 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 "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
