On Jan 7, 7:33 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > 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?
No, not in my mental image of the setup. Take the following, DEFAULT_ENGINE = 'postgresql_psycopg2' DEFAULT_NAME = 'my_database' DATABASES = { 'default': { 'ENGINE': DEFAULT_ENGINE, 'NAME': DEFAULT_NAME, }, 'read_slave': { 'ENGINE': DEFAULT_ENGINE, 'NAME': DEFAULT_NAME, 'TEST_NAME': None, }, } So the important thing here is that 'read_slave' *is* defined, but in my local test settings it uses the same `DATABASE_NAME' (and host, user, password, port) as my `default'. The `TEST_NAME = None' change will simply allow me to get past the error caused when `read_slave' tries to drop and create a database that `default' has an open session to (it just dropped and created itself, after all). Now in code like, MyModel.objects.using('read-slave').filter(...) That should be a valid connection (`DATABASES['read_slave']') but it's actually connecting to the exact same DB as `default', so a filter should find objects created on `default', just like you'd imagine in a real world read-slave setup. Does that make more sense? There's really nothing magic going on here, it's only a matter of telling it not to drop/create the DB. I think maybe `TEST_NAME = None' could be confusing? I didn't mean to imply that the alias wasn't properly setup and functional. 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.