Jacob Kaplan-Moss wrote:
> On Jul 10, 2006, at 10:09 PM, jason pellerin wrote:
> > Thanks, Jacob. And yes please, more eyes are badly needed. Aside from
> > dropping tables, the branch is fully functional -- please try it out!
>
> I've svn swich'd and I'm fooling with it now...
Cool! I'd suggest starting by reading the tests, othertests/ansi_sql.py
othertests/manager_schema_manipulation.py, and
modeltests/multiple_databases/models.py, if you haven't already.
django/db/backends/ansi/sql.py has the schema manipulation code moved
from django/core/management.py, and there are small changes wherever
db.connection or db.backend was imported, to look those up via the
current model.
> I'd imagine the best way to do it would be to have the ``Manager``
> look up the database connection it's supposed to use (at ``__init__``
> time, probably). That way the lookup would only happen at model
> definition time, not repeatedly for each query. Storing it in
> ``opts`` would be OK, but IMHO a bit ugly since ``opts`` is usually
> reserved for "stuff defined in ``Meta``". Thus you could find out
> which connection a model is using by checking
> ``Model.objects.connection`` (or something other than ``connection``,
> of course).
My underlying opinion is that *all* database-access code should go in
or be referenced through the manager, so I'm all for moving the
connection/connection_info cache there.
If connection/connection_info isn't clear: connection is a
DatabaseWrapper, same as the default django.db.connection.
connection_info is a django.db.ConnectionInfo instance, which
encapsulates all of the metadata about the connection. For instance,
that's where you get at the backend used to create the connection, the
creation module, etc. I'd be quite happy to see the ConnectionInfo at
Model._default_manager.db, which would make the connection
Model._default_manager.db.connection.
> Yeah, I'm not sure I like that... what if I have an app with the same
> name as my database? There's at least one Ellington install I know
> of that has "ellington" in ``INSTALLED_APPS`` and uses a database
> named "ellington"...
That wouldn't matter. Maybe if I take out some ellipses it'll be more
clear:
DATABASES = {
'ellington': { 'DATABASE_NAME': 'ellington',
'DATABASE_ENGINE': 'postgresql',
# DATABASE_USER etc
},
'myproj.myapp': { 'DATABASE_NAME': '/var/db/readonly.db',
'DATABSE_ENGINE': 'sqlite3'
},
}
The key in DATABASES need not have any relation to the DATABASE_NAME
setting it references. It seems I'm growing more partial to this as the
simplest solution, so I'd better think of some compelling arguments. :)
> I'm running a bit dry on other ideas, though...
Hm... an APP_DATABASES setting to map apps to databases? Ugly. Nothing
else is coming to mind, though.
> > Maybe a
> > warning in management.validation if a model references a model that
> > the current settings put until a different connection?
>
> Yeah, that sounds perfect to me.
Excellent. Added to my TODO list on the wiki.
> I posted a couple of example use-cases in response to Malcolm.
> Manually setting ``db_connection`` is ugly but workable; I'll think
> some more about a more elegant way of doing it.
I think Malcolm is right -- if the manager holds the connection, this
problem practically goes away. So long as the manager also implements
save() and delete, that is. Totally made-up example:
class RemoteManager(Manager):
def get_db(self):
return RemoteConnectionInfo()
class Mod:
objects = Manager()
remote = RemoteManager()
# read local, write remote
for m in Mod.objects.all():
Mod.remote.save(m)
JP
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
