Database routers are for routing database queries. Forms and ModelForms are for validating user input. If you want to route an update to a specific database using a ModelForm, then you're going to have a bad time, ie. you'll need to write a lot of code for the specific API that you want, as opposed to writing a handful of lines for a custom router (that *will* let you specify a database at runtime).
Not sure I can put it more plainly than that ¯\_(ツ)_/¯ On 9 August 2016 at 15:07, Ben Finney <[email protected]> wrote: > Anthony Briggs <[email protected]> writes: > > > On 9 August 2016 at 14:29, Ben Finney <[email protected]> > wrote: > > > > > I'm wanting to specify *exactly one* database at *run-time*, and > > > have the operation use *that* database only (or fail if it can't). > > > The configured multi-database routing is no use for that. > > > > You seem to be very focused on one specific, tactical thing which cuts > > across the grain of how Django works. > > That would be true, if not for the fact that I've provided numerous > examples where Django explicitly provides the ability to specify at > run-time exactly which database to use. > > So in that light, it's already something Django is evidently comfortable > doing. > > I'm open to the idea that Django's ModelForm can't do this; but it seems > perverse to say that a feature provided explicitly and officially in > many other closely-related parts is “cutting against the grain of how > Django works”. > > > You can get what you want, but it involves hollowing out ModelForm and > > replacing most of the code to couple it to the database. > > So, rather than use a ModelForm for validating field values and creating > the model instance – very much in line with what the ModelForm is meant > to do – > > > OTOH, the router is just a class whose methods return strings, so you can > > make it do whatever you want. > > … you're instead advising me to cut across the grain of how a database > router works (i.e. I don't want it to choose based on a configured > policy; I don't want it to fall back to the ‘default’; I need to specify > it at run time; I need it not for whole classes of operations but only > at the point of creating a Model instance; etc.) and hollow most of it > out, to do a specific, tactical thing that isn't part of what it's meant > for. > > I'm open to being convinced otherwise, but so far the evidence is > heavily *against* using that tool for the requirements I've described. > > -- > \ “… one of the main causes of the fall of the Roman Empire was | > `\ that, lacking zero, they had no way to indicate successful | > _o__) termination of their C programs.” —Robert Firth | > Ben Finney > > _______________________________________________ > melbourne-pug mailing list > [email protected] > https://mail.python.org/mailman/listinfo/melbourne-pug >
_______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
