On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee
<[email protected]> wrote:
> On Fri, Jun 4, 2010 at 11:54 PM, [email protected] <[email protected]> wrote:
>> Hi Russell,
>>
>> I strongly disagree with your and Adrian vision of whether conventions
>> are good or not.
>> But I won't comment that any further. There are your political
>> decisions, and I have no single bit of control on them.
>> I know that it's impossible to persuade you, so why should I spend my
>> time doing this.
>>
>> However, you didn't tell anything on the problem that was the main
>> reason why I wrote this app.
>> Additive variables.
>>
>> DATABASES, DATABASE_ROUTERS, MIDDLEWARE, etc.
>> Do you think situation will change with them?
>>
>> In example, I want few of my apps to work with their own databases.
>> They need to install their database into DATABASES and their router
>> into DATABASE_ROUTERS.
>>
>> How would you do that?
>
> Like Tom said - you don't solve it by configuring the app. You
> configure the way a project uses an app, not the way an app should be
> used in a project. His example for configuring DATABASES is right on
> the money.
>
> As an example of why the 'app configuration' approach fails, consider
> the case of reusable apps. A reusable app can suggest defaults for
> settings, but once a reusable app you wrote is in my project, I need
> to configure it to conform to my local conditions. Your app *cannot*
> know what database it needs to use when it's in *my* project. That's a
> project configuration issue for me.
Actually, some of my apps know what database they need to use, cause
they always use the same databases at the same database server unless
these apps are used for development. These are well established
applications and they have fixed names for databases (you can override
the names, but the names are very specific so you will never need to
override the names).
This is exactly why such app sets its own database options in global.py .
And for each development machine I have
conf/development_machine1__overrides.py which contains overrides.
I believe it's better than having "if socket.getfqdn() ==
'development_machine1':" conditions in settings.py
But, if *my* app doesn't know what database to use in *your* project, then:
1. It will provide sensible and customizable defaults for app-specific
database and app name (let's call them app.LABEL and app.DB) in its
own options namespace (yes, GSoC app loading feature will handle
that).
2. That variable will be used for its router.
3. Router will add itself into DATABASE_ROUTERS
4. No any settings will be added into DATABASES.
And if your used django-configurator, then the rules are pretty simple:
5. Database will be added into the list of the databases in conf/global.py
6. For development machine(s), this database will be overridden in
conf/development_machine1__overrides.py
In your case the configuration will be like this:
FOO_APP_DB_NAME = 'fooapp'
FOO_APP_APP_LABEL = 'fooapp'
DATABASES = { 'default': { ... }, 'fooapp': { ... }, }
if socket.getfqdn() == 'development_machine1':
DATABASES['fooapp'] = { ... }
DATABASE_ROUTERS = ('fooapp.routers.Router',...)
I had this before django-configurator, and I don't think it was any
better than it is now.
You can't even do
from foo_app.settings import *
cause that won't let you to add a router or set up a database!
(well, you can do
import_from_file(locals(), socket.getfqdn().replace('.','_').replace('-','__'))
but it's effectively the same I do in configurator.autodiscover(locals())
hm... do you think this one is a common boilerplate for importing
machine-dependent settings?
)
As alternative, maybe, do we need a registry for routers instead of
settings variable?
The same question should be asked for other additive variables in
settings.py of course.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [email protected]
--
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.
