I am fine with the proposed change to allow better routing of RunSQL/RunPython (though in the RunPython case people can easily do routing inside the python code provided anyway, as you can see the DB aliases there).
Aymeric: The problem with your proposal is that there's no easy way to get the versioned model that the migration is using from just (app_label, model_name); we'd need to pass the Apps instance in there as well. At least if the whole model instance is around it'll be the correctly-versioned one from the right point in time (I'm not sure if that makes a big difference to most routers but it will stop lookups failing for models that have since been deleted, for example) Andrew On Tue, Feb 17, 2015 at 12:58 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 17 févr. 2015, at 11:06, Loïc Bistuer <loic.bist...@gmail.com> wrote: > > > The proposed fix for the release blocker > https://code.djangoproject.com/ticket/24351 suggests changing the > signature of the `allow_migrate` database router. > > > > From: > > def allow_migrate(self, db, model): > > > > To: > > def allow_migrate(self, db, app_label, model, **hints): > > > > We need to make a design decision. > > It appears that we have the change the signature of this function one way > or another and that inspect.getargspec is our only option to preserve > compatibility. > > Did you consider the following signature? > def allow_migrate(self, db, app_label, model_name=None, **hints): > > While it’s a slightly larger change, it has a several advantages: > - passing (app_label, model_name) as strings is an established convention > in many other APIs. > - it removes the possibility that app_label != model._meta.app_label — > which doesn’t make much sense anyway. > - our examples only ever use app_label — and keep repeating > model._meta.app_label to get it. > > If the model class is needed, it can be fetched with > apps.get_model(app_label, model_name). > > -- > Aymeric. > > PS: we chose to make 1.8 the next LTS instead of 1.7 precisely so we could > make such adjustments. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/B42BA226-16FE-43D5-BE12-8FFD3DCD3094%40polytechnique.org > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uo2tSTOUdZy0nAAftcEXGGdcZmezWCThkM9ePYe3_brFw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
