Am 05.12.2009 um 06:36 schrieb Russell Keith-Magee:
> [...]
>> What if the admin was instead fixed
>> by providing facilities for the more general case outlined above?
>>
>> What would this look like? I'm picturing another setting (bleh) that
>> maps apps and/or models to specific databases. Name choices aside,
>> this might look something like:
>>
>> DATABASE_USING = {
>> 'django.contrib.auth': 'default',
>> 'myapp': 'database1',
>> 'myapp2': {
>> 'Model1': 'database2',
>> 'Model2': 'database3',
>> }
>> }
>>
>> The admin could automatically take advantage of this setting to
>> determine what database to use for a given model.
>
> Alex, Joseph Kocherhans and I discussed this exact idea at Djangocon.
> You are correct that it has a lot of potential uses - not only the
> admin, but also loaddata/dumpdata, syncdb, and anywhere else that an
> iteration over models is required.
>
> However, it's a little bit more complicated than you make out.
>
> This sort of setting is very easy to give as a 10 line example, but in
> practice, this isn't what you will require - you will effectively need
> to duplicate the contents of INSTALLED_APPS. I have projects in the
> wild with dozens of entries in INSTALLED_APS - all running on a single
> database. Writing a DATABASE_USING setting like the one you describe
> would be extremely cumbersome and annoying.
>
> So, we could hijack INSTALLED_APPS to represent the idea of database
> deployment, using tuples/dictionaries rather than strings to define
> how apps are deployed. However, this comes at the cost of backwards
> compatibility for anyone iterating over INSTALLED_APPS.
> [...]
Let me propose a different colored pattern. It's backwards compatible,
dry, feels like the urlconf approach and may evolve into a fix for
#3591:
INSTALLED_APPS = (
app('django.contrib.auth', using=...),
app('myapp'),
app('myapp2', models=(
model('Model1', using=...),
model('Model2', using=...),
),
)
Where `app()` would look like this:
APP_USING = {}
def app(path, **kwargs):
if 'using' in kwargs:
APP_USING[path] = kwargs['using']
...
return path
The downside: It would require an import in settings.py. And the
global dict is not exactly beautiful - but the price for bc.
This is not really an argument for a settings based solution (+0). But
if there will be one, don't make it nested tuples/dicts - the
existance of tuple literals in python does not make s-expressions a
natural representation of configuration.
__
Johannes
--
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.
