On Dec 19, 6:48 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > You're right - read slaves are an intended common use case
I know the branch landed but I'd like to mention another issue regarding read-slaves, hope that's OK. :) Running tests against code that uses master and read-slaves (but actually point at the same exact DB while testing) is currently not possible. When the tests begin each DB is expected to be started fresh (the runner stops if it cannot), so you can't use the same DB name/ host for two entries in settings.DATABASES. I think it's awfully common for people not develop with *actual* read-slaves on their local machine, but rather to use the abstractions available and point their "read-slave" at the same information as their default DB. I could just set TEST_NAME for the read-slave to something else, but in our production code and tests (as an example) we'll have some test inserting data on master and another using it via a read-slave. Unless I'm missing something, we'd have to create all data on both the master and read-slaves in order to test properly, which is awfully awkward and possibly confusing. Any thoughts? Off the top of my head all I can think of is that the test setup could check if any DBs match up in name/host and not try to drop/create after the first. Thanks, 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.
