On Fri, Jan 8, 2010 at 3:17 AM, Brett Hoerner <br...@bretthoerner.com> wrote:
> 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?
I completely agree that you don't need to have read slaves in order to
test application logic (unless, of course, you're checking your read
slave selection behavior).
However, I'm a little confused as to how your setup will work with the
change you propose, If you have a database setup with:
"read-slave": { ... TEST_NAME=None },
then my understanding of your proposal is that the only change is that
read-slave won't get created under the test setup. But doesn't that
mean that::
MyModel.objects.using('read-slave').filter(...)
will fall over? Either the read-slave alias won't exist in DATABASES
(if we fully clean up the DATABASES setting), or the read-slave alias
will point to a database with no name.
In your opinion, how does using() (or the test framework) compensate
for a database alias that is referenced in code, but non-existent
during testing?
FYI - I've opened #12542 to track this particular issue. I've also
opened #12541 to track the cross database validation/read slave
identification problem you raised earlier.
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 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.
