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. 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.
