On Jan 7, 7:33 pm, Russell Keith-Magee <[email protected]> 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 [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.
