> On Feb 18, 2015, at 05:18, Andrew Godwin <and...@aeracode.org> wrote: > > 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).
True although that tightly couples the host migration and the routing step. It is fine if you control both but you are out of luck if the migration is in a reusable or third-party app. > On Tue, Feb 17, 2015 at 12:58 PM, Aymeric Augustin > <aymeric.augus...@polytechnique.org> wrote: > > 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). It's a fair proposal but it's hard to predict what people currently do with their routers. I've only ever needed to "identify" models, so it would suffice for my needs. The only (slightly convoluted) use-case I can think of is pushing the routing decision onto a model or manager method. For model methods you'd have to be a bit crafty by using non-model base classes, and for manager methods you'd have to use Django 1.8 since custom managers weren't supported before. In both cases versioning is bypassed and there is the requirement that classes still exist in the codebase, but at least it's not coupled to the existence of a specific model like `apps.get_model(app_label, model_name)` would. It's a tangent but seeing this, we should definitely turn the `model` (or `model_name`) arg into kwarg even if only in the docs, that'll make it more obvious that it's not always there. > PS: we chose to make 1.8 the next LTS instead of 1.7 precisely so we could > make such adjustments. +1 -- Loïc -- 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/E5E8EEBA-CA5B-43CF-8D0E-B044CE20B5D8%40gmail.com. For more options, visit https://groups.google.com/d/optout.
