On Mon, 2006-07-10 at 22:09 -0500, jason pellerin wrote:
> Hi all,
>
> Thanks, Jacob. And yes please, more eyes are badly needed. Aside from
> dropping tables, the branch is fully functional -- please try it out!
>
> > I'd like to see this done the other way around, which the DATABASES
> > settings defining which *models* are used. I'm picturing something
> > like this::
> >
> > DATABASES = {
> > 'a' : {
> > 'DATABASE_ENGINE' : 'sqlite3',
> > 'DATABASE_NAME': '/whatever/foo.db',
> > 'APPS' : ['myproject', 'yourproject.widget',
> > 'someotherapp']
> > }
> > }
> >
> > So each member of APPS is either an app specifier (as you'd pass to
> > models.get_app) or a model specifier (as you'd pass to
> > models.get_model). This way each site can specify different
> > databases for different apps or even individual models.
>
> This is interesting. How would it work -- look up the APPS in each
> settings entry at model class creation time, and fill in
> opts.db_connection that way? Or do you want to get rid of
> opts.db_connection entirely? I'd prefer to keep it -- for one thing,
> without that attribute around, the work to find the proper connection
> will have to be repeated every time the connection is requested. (If
> it's understood to be more of a connection-name cache rather than the
> prefered point of configuration, that's ok with me.)
>
> I'm not sure that tucking APPS into the db-definition dict is the
> right thing, though. This may be too "magical", but how about: the
> keys in DATABASES could be app or model names, and in that case,
> matching apps/models will use the connection for that key. Example:
>
> DATABASES = {
> # symbolic names are still ok, but you'd have to set them in the model
> 'a': { ... },
> # but specify an app or model and that app or model will use this
> connection
> 'myproj.myapp': { ... },
> 'thatproj.thatapp.ThatModel': { .... }
> }
Under Jacob's proposal, if I have five applications and all the models
in each application use the same connection, I need to write out (at
most), DATABASE_ENGINE and DATABASE_NAME once for each engine/name pair
and I need write the application names once.
Under your proposal, I need to write DATABASE_ENGINE and DATABASE_NAME
once for each application, because there is no way to group the
information is even one of my applications needs a different database.
That seems like a lot more configuration (longer config files are harder
to debug, too).
I would prefer to get rid of the option of putting it in models
altogether, having read Jacob's reasoning: having multiple ways to do
something seems unnecessary here (is it necessary for some reason I
haven't thought of?) and it is encouraging non-portable, difficult to
debug problems when moving applications around. What advantages does it
add that you see?
Jacob's approach still leaves you with a natural key to use when trying
to refer to the connection directly (so keeping DATABASES as a
dictionary, rather than just a list of dictionaries is worthwhile).
>
> That seems pretty natural and clear to me, at least.
I am unconvinced. :-)
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
