On Sat, Dec 19, 2009 at 1:41 AM, 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. ;)
You're right - read slaves are an intended common use case, and the cross-database checks will get in the way for that case. I quite like the solution you have proposed. However, the exact interpretation and consequences need to be thought about a bit - the issue of whether an object originating from the slave gets state.db set to the slave it came from or the master is one such problem. I strongly suspect the answers won't be too complicated (or particularly counterintuitive), but I don't want to rush it just in case we get it wrong on the first attempt. For the purposes of commit next week, I'll strip out the cross-database checks. We can always add stronger checks once we've got the code out there in the alpha release and we've had time to have a full discussion about how to address the master/slave problem properly. 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.
