Re: Feedback requested: One last time with multi-db

2010-01-26 Thread Brett Hoerner
On Jan 23, 7:05 am, Russell Keith-Magee 
wrote:
> A full explanation, including an example is in the documentation
> portion of the patch, attached to ticket #12542.
>
> Comments?

This fixed our only (known) blocking problem towards 1.2, thanks so
much.

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.



Feedback requested: One last time with multi-db

2010-01-23 Thread Russell Keith-Magee
Hi all,

This is a call for comments on what I hope will be the last two
modifications to multi-db support for 1.2.

Barring negative feedback, I aim to commit this at the start of next
week, just in time for the beta-1 feature freeze.

Change 1: Identifying which models are on which database
--

To date, we have avoided any housekeeping over which models are
available on which database. We have made the assumption that all
models are available everywhere, and left it up to the user to
manually configure their database if this isn't the case.

This has a couple of consequences:

 * If you want to restrict some models to certain databases, you can't
use syncdb - you need to take the manual route. This isn't a
show-stopper, but it is a lot more complication than Django usually
requires.

 * It is impossible to do completely generic metaprogramming - you
can't, for example, build an admin interface that only displays the
right models for the right databases, because there isn't an easy way
to determine if a model is available on a given database. Again,
manual configuration is possible here, but similarly complex.

 * The test system must assume that every model is on every database
(since there is no opportunity for manual synchronization). This means
you can't explicitly test behavior that relies on non-availability of
a model on a particular database.

I've opened #12672 to track the issue, and there is a candidate patch
ready for comment. This patch follows an idea originally from Johannes
Dollinger, and refined by Yuri Baburov - that we add a method to the
database routers that can answer whether a specific model is available
on a specific database. This method (allow_syncdb()) follows the same
pattern as allow_relation(); return True if a model should be on a
database, False if it shouldn't, and None if the router has no
opinion. The bucket behavior is to allow all models on all databases,
so there is no change to the current behavior if you don't have
routers installed.

The other benefit of this approach is that we can drop the --exclude
arguments from loaddata and syncdb. Personally, I was never happy with
the fact that we needed to introduce these arguments as part of the
first multi-db patch, but they were a necessary evil caused by the
lack of info about model database assignments. Since the need for
these flags is going away, I've taken the opportunity to remove them.

Code, tests and documentation is in the most recent (v2) patch on
ticket #12672. Comments?

Change 2: Test mirrors
--

The second change involves a change to the test system to handle
multiple database setups. I have introduced a new test setting --
'TEST_MIRROR' -- that redirects a particular database alias to point
at a different connection while in the test environment.

This is required for testing of master/slave setups. The short
explanation is that the temporary databases that the test environment
creates won't be created with any data replication strategy in place,
which will break any tests that expect replication to occur.

A full explanation, including an example is in the documentation
portion of the patch, attached to ticket #12542.

Comments?

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.