On Sat, Dec 5, 2009 at 4:07 PM, Johannes Dollinger
<johannes.dollin...@einfallsreich.net> wrote:
>
> 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.
The idea of using a function that returns a single string but does
other processing is a novel approach, and one that I hadn't
considered. However, I'm not sure I'm especially fond of the idea of
requiring imports in a settings file, and the syntax you propose is
quite verbose. I'll have to think about this a bit. Thanks for the
suggestion, though.
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.
