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.
