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': { .... }
}
That seems pretty natural and clear to me, at least.
> Second, there's no mention about how relations will work across
> databases. I'm sure we *could* emulate them, but I'd suggest
> throwing a nice error if you try to reference a model that's in
> another database.
There's a *little* mention in the tests. :) My preference is not to
enforce this sort of thing, but let the database do it when needed.
Mainly because one of the big use cases for me is the ability to use a
local sqlite cache on a spread of webservers. The caches are published
from an admin db, but only the appropriate public tables are sent; so
there may be models and relations that appear to cross connections on
the public side but share a connection on the admin side. Maybe a
warning in management.validation if a model references a model that
the current settings put until a different connection?
> Finally: will there be syntax to use a specific connection for some
> operations even if that model's set up to use a different backend?
> I'd hope so, but I'm not sure I can come up with a good syntax...
Well, you can always set Model._meta.db_connection = 'foo' at any
time. Or create a manager that pulls the connection to use from
someplace other than self.model._meta.connection, though that would be
difficult without some additional abstraction. I'm not quite sure what
the use of this would be, but that may mean there's a need that I just
can't see.
> OK, thoughts, anyone?
What he said. :)
JP
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
