On Sun, Jan 3, 2010 at 10:52 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Sun, Jan 3, 2010 at 4:06 PM, CB <cbw...@gmail.com> wrote: > >>> The >>> default implementation would essentially be: >>> >>> def db_from_related_object(self, instance): >>> return instance._state.db >> >> I'm not familiar with ._state and not sure if you're referencing >> existing attributes on the manager, but I can see what you're getting >> at. > > FYI: _state is the per-instance analog of _meta. It's an instance > specific store of instance specific "state" - like the database that > was used to source the object. > >>> Given >>> that this is a fairly glaring hole in the API, I'm certainly open to >>> providing a fix in the 1.2 timeframe. >> >> I'm not too familiar with when exactly this timeframe is - if it's >> still a bit away and this doesn't count as a 'feature' (i.e., I have >> maybe a week or so) I might try writing up a patch. > > The current timeframe targets a feature freeze on January 26th, with a > full code freeze on March 2. If we can get something in place for the > feature freeze, that would be ideal; depending on the exact nature and > scope of the changes required, I might be able to convince people to > let this sort of change in after the feature freeze. > >> We probably should name / detail these partitioning strategies so we >> can discuss them easier: >> >> 1. Follow Original DB: Always resolve relations by staying on the same >> DB as the source relation >> 2. Force Model DB: Always resolve relations by using >> >> The code I posted above sticks with option 2, and treats an un- >> dbassigned model as assigned to 'default'. > > There is an additional special case of (2) that is required by > master/slave. Although objects may be retrieved from slave, they are > really 'from' the master database, and two objects retrieved from > different slaves are actually compatible. It was this use case that > originally led to the cross-database checks being relaxed. At the > time, there was discussion about adding a database setting to provide > a point of commonality between databases. > > I appreciate that this particular use case doesn't affect your > particular needs, but it should be kept in mind while we are working > on the general data source problem.
Hi CB, FYI - I've just uploaded a patch to #12540 that implements a strategy similar to what I described. I'd be interested in hearing any feedback you may have. Yours, Russ Magee %-)
-- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
