Hi Jacob,
I'd be interested in your thoughts on a declarative approach to defining the
other databases...? I'll have my mercurial repo synced up to trunk tomorrow
(my time) and I'll re-apply the patch I got from Daryl to it as a starting
point. Hopefully people will be able to have a look through it and compare
the declarative approach proposed with the existing multi-db approach.
As far as I can tell, you've currently provided two hooks to use a
> secondary connection: set the model's default connection in the
> settings module (which is OK, I suppose, though I might want to
> nitpick the syntax a bit), and assigning to ``Model.objects.db``.
>
> This second one is a disaster waiting to happen -- you've had to muddy
> things up with threadlocals to work around some problems already. Also
> consider the "bookkeeping" you'd need to do to deal with objects
> across multiple database simultaneously (think sharding). You'd have
> to keep juggling ``Model.objects.db`` and saving old ones... ugh.
I built a non trivial application with multi-db as it is right now and found
the api to be a bit hairy to be honest. I think it would be an advantage,
especially in a "database rich" environment to be able to build a db on the
fly much like a model, rather than be tied to what's in a dict in settings.
I don't really like the objects.db way of doing it, and I found myself doing
a fair bit of hacking to get it to work.
> * There needs to be an official API to get a model (or perhaps a
> manager) which references a different "context" --
> ``Model.objects.db`` should be read-only. So you'd call some API
> method, and get back a sort of proxy object that uses the other
> connection. Here's a strawman API::
>
> >>> from django import db
> >>> from someapp.models import Article
>
> >>> Article.objects.all()
> [... all Articles from the default database ...]
>
> >>> ArticlesOnOtherDatabase = db.get_model_for_other_connection(Article,
"private")
> >>> ArticlesOnOtherDatabase.objects.all()
> [... all Articles from the database defined with the "private" key ...]
Agreed, the way I got round this was to build the model again from scratch
each time I wanted to access objects in a different database and have the
dynamicaly created model persist in the app cache. I took most of this from
the dynamic models entry on the wiki, it's here, look in the duplicate_model
function:
http://www.djangosnippets.org/snippets/442/
This would really need work (especially the field copying code, which is
fairly horrifying! I know that doesn't work for all field types too - yuk)
before it becomes a 'good idea', and I'm not even sure it's the right way to
go, however I'd be interested in weather people think it's a valid approach.
* I'd like the default connection for each and every object to be the
> default database forever and always. I find putting models for default
> connections in settings distasteful and I'd rather just a single API
> for changing the connection (see below). However, I imagine I'll be in
> the minority here so I'm prepared to cede this point if necessary.
The API which I think is being proposed is that there should be a central
register for database connections. In my mind this would be the place to go
to get hold of a connection for use in a queryset (and all the other places
it's needed) and I think the correct default behaviour of the class/object
would be to return the connection defined in settings.DATABASE_*. The code
to build the declarative DatabaseWrapper is already there, and there a
method to build one of these from what's in settings too. This should make
it easy to get hold of connection in all of the places where we currently do
"from django.db import connection".
It's great to see this revived again :-)
Cheers
Ben
--
Regards,
Ben Ford
[EMAIL PROTECTED]
+447792598685
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
