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...
> 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.)
Hmm...
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).
> I'm not sure that tucking APPS into the db-definition dict is the
> right thing, though.
Yeah, I'm not really that happy with my syntax; it's just a strawman
to get us thinking about ways to define the connection in the
settings file.
> 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.
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"...
I'm running a bit dry on other ideas, 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.
>> 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.
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.
Jacob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
