On Sun, Dec 6, 2009 at 1:09 AM, Tobias McNulty <tob...@caktusgroup.com> wrote:
> On Sat, Dec 5, 2009 at 10:51 AM, Russell Keith-Magee
> <freakboy3...@gmail.com> wrote:
>>
>> I don't grant that proposition at all. The admin interface serves as a
>> working example demonstrating that you don't need to use settings to
>> define the way models are used.
>
> Okay.  Do you grant the proposition that "we will (not necessarily in Django
> 1.2) need a project-level way to specify the default database(s) to use for
> queries to a given model," whether it is settings-based or not?

Possibly. :-)

>> At this point, I'm prognosticating because I haven't actually written
>> any code for this - but I don't think the using argument to Site()
>> would necessarily have to be deprecated. In a single-database admin,
>> the using argument tells you exactly which database is to be used; if
>> we update admin to have a fully multi-db interface in the future, the
>> value of the using argument could easily be interpreted as the
>> "default" database that is displayed.
>
> Maybe I'm just being obtuse, but there are a couple issues with the admin
> approach to which I can't see a resolution yet:
> * Assuming the above proposition is true, the behavior of the API when the
> global and admin-level configurations conflict is not at all intuitive

I'm not sure how you can make that assertion given that neither global
nor admin-level configurations for multi-db exist yet.

Might I humbly suggest that we stop speculating about the possible
limitations of a theoretical admin implementation until such time as
an implementation actually exists?

> Simon's idea seems like a reasonable (and already supported?) workaround for
> those who need to modify the admin to use a different database in specific
> cases.

Agreed. All I'm talking about is making it easier to do what Simon has
suggested, but without the need for boilerplate ModelAdmin
definitions. I'm hoping to spend the next couple of days fiddling with
this problem. Once we've got something concrete to argue about, I'll
report back.

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.


Reply via email to