On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com <burc...@gmail.com> wrote: > On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Fri, Jun 4, 2010 at 11:54 PM, burc...@gmail.com <burc...@gmail.com> 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).
... until the very first time that you *do* need to. Seriously - you simply *cannot* make any assumptions about the deployment environment in which a user will be using your app. Every single time in my life I have made the statement "Nobody will ever want/need to..." I have been proven wrong. Consider it a corollary of Rule 34 :-) > 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 And to all of this, I'd fall back on the Zen of Python: explicit is better than implicit. IMHO, this is doubly true when dealing with something as critical as configuration -- personally, I want my configuration files to do *nothing* surprising or automatic. For example - you say that your application needs to run in a separate database. My DB Admin (or hosting provider) won't let me have another database instance. How does your automated "add this extra database" approach handle the case where I don't want you to add another database? > 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. Again, I don't see why. IMHO we should be letting the end user configure their site, not try to impose a semi-automated partial configuration gathering scheme, and then provide a scheme for the end user to override the default autoconfigured setup (and trust me - no matter what scheme you propose, there *must* be a way to override it, because it doesn't matter how smart you are - someone out there will have needs that step outside the capabilities of your implementation). 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.
