Russ,
Your gut feeling confirms my suspicion.
Changing the lines to the following fixes my problem:
db = model_instance._state.db
if db is None:
db = router.db_for_write(model_instance.__class__,
instance=model_instance)
qs =
self.rel.to._default_manager.using(db).filter(**{self.rel.field_name:value})
The validation of many2many fields (further down in the same file) has
a similar issue and would need fixing too.
I'll file a bug on the topic.
I somehow feel a bit uncomfortable with this approach: the formfield
constructor accepts the "using" argument to direct the queries to a
database, but since the validation is model-based (not form-based)
that info is not used in validation. You rely on guess-work like the
above or on the fact that the routing logic is in sync with the
"using" argument you provided. This can't be DRY...
Regards,
Johan
On Jun 16, 2:25 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Tue, Jun 15, 2010 at 9:11 PM, johan de taeye
>
>
>
> <johan.de.ta...@gmail.com> wrote:
>
> >> You can't do this with a router; as you've noted, the router doesn't
> >> have any information about the request in which it is being used.
>
> >> However, you could do it by manually requesting your database
> >> connection whenever you use the database. For example:
>
> >> Author.objects.using('otherdb').filter(...)
>
> >> will perform a query that is guaranteed to operate on the 'otherdb',
> >> regardless of what the router says.
>
> > I was able to get this part working fine. Since most views are based
> > on a reuable generic one this was pretty easy to do anyway.
>
> > Getting ModelForms (or ModelAdmin) to work with foreign keys is a
> > different story: When the form/model is validated, the field value is
> > searched in the source table to verify the key exists. This lookup
> > uses the _default_manager (see code below), which isn't aware of the
> > request any more and always checks on the default database (unless I
> > can route it). As a result I always get a validation error on the
> > form.
>
> > Looks like I need a patched/smarter RelatedField that is aware of the
> > database to look in?
>
> You're in somewhat uncharted territory here, so I can't give you a
> simple prepared answer. However, you certainly appear to be on the
> right track.
>
> It's also possible that you've discovered an edge case bug -- looking
> at the code, my gut tells me that the _default_manager call should be
> forced onto the same database as model_instance - i.e., the query
> should be:
>
> db = router.db_for_read(self.rel.to, instance=model_instance)
> qs =
> self.re.to._default_manager.using(db).filter(**self.rel.field_name:value})
>
> or similar. I'd need to do more tests to confirm this, though. Feel
> free to log a bug if you can reduce this to a test case that
> demonstrates that this is indeed a bug.
>
> 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.
