2015-02-18 14:07 GMT+01:00 Loïc Bistuer :
> Individual routers don't have a base class but we can add it to the master
> router `django.db.router`. I've updated the PR with a
> `router.allow_migrate_model` method. I don't know if we should document
> this just yet.
>
Good. Unless I missed somethi
Loïc, the model_name is indeed the lower-case version of the
object_name:
https://github.com/django/django/blob/master/django/db/models/options.py#L203
On Wednesday, February 18, 2015 at 2:07:28 PM UTC+1, Loïc Bistuer wrote:
>
> Individual routers don't have a base class but we can add it to the
Individual routers don't have a base class but we can add it to the master
router `django.db.router`. I've updated the PR with a
`router.allow_migrate_model` method. I don't know if we should document this
just yet.
Internally we now treat anything other than `app_label` as a hint, but I guess
2015-02-18 6:34 GMT+01:00 Loïc Bistuer :
> Another option would be to make the signature `allow_migrate(self, db,
> app_label, model_name=None, **hints)` and to put the model class in the
> hints dict, the same way we pass `instance` as hint to the other routers.
Yes, that's what I wanted to sug
Another option would be to make the signature `allow_migrate(self, db,
app_label, model_name=None, **hints)` and to put the model class in the hints
dict, the same way we pass `instance` as hint to the other routers.
That would make the 80% use-case less fiddly without any loss of functionality.
> On Feb 18, 2015, at 05:18, Andrew Godwin 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
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 ver
On 17 févr. 2015, at 11:06, Loïc Bistuer 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,
Hi Tim,
The API doesn't assume anything, it just gives to the router all the
information that's available, which is limited to connection_alias and
app_label in the case of RunPython/RunSQL.
Previously all RunPython/RunSQL operations would run on every db no matter
what, this is obviously brok
I'm not a big user of multi-db so I could be wrong here, but it seems like
this API seems to assume that all models in a given app are stored in the
same database. Have you thought through what happens if this isn't true?
This question seems to come into play when we allowed model=None in
RunPy
10 matches
Mail list logo
