On Jan 5, 8:09 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> If you're actually doing master/slave in the wild, your guidance may
> actually be more enlightening than my theoretical navel gazing. In
> particular - how have you got master/slave configured? How do you find
> and select slave databases? How does that approach degrade when
> DATABASES suddenly has less entries (including the case of a config
> with no slaves)?
Yes, we're actually doing read-slave queries on Django 1.0.x using
some private API hacks.
We basically have the same layout of DATABASES that multidb went with,
but we only use different managers to dispatch queries. In other
words, `Foo.rs_objects.all()' vs `Foo.objects.all()'. It's pretty
basic, but it's worked for us.
So that's equivalent to the `using' syntax, you can just imagine we
have places in our code where the developer knows that read-slave
replication isn't a problem and we want to offload a query, so
`Foo.objects.using('read_slave')...' is used. We don't do any special
selection right now, `DATABASES['read_slave']' is hard coded per
deployment instance, different instances might use different read-
slaves for various reasons but those reasons also require us to use
whole different app servers too, and so those requests are chosen by a
frontend proxy rather than some in-app magic.
Anyway, most of that doesn't really matter, I think. What matters is
that we don't do any special degrading if `DATABASES' is different.
As soon as you use `using' (or our equivalent) you're hard coding the
use of another DB name, so in development we just have `DATABASES
['read_slave']' use the same settings as `default' does.
So in the end the `TEST_NAME=None' solution works well for our case at
least, I would imagine for any number of read-slaves you'd want to be
able to point them at the `default' DB (without doing a dump and sync)
during tests - I mean, that's what a read-slave is, no?
Regards,
Brett
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
