Signature of the allow_migrate database router.

Hi all, 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 d

Re: status of 1.8 release blockers

So, it turns out that #24291 (Migrations fail with unused swappable model) only occurs when a swapped out model doesn't define an explicit model manager. Since auth.User is the only model that is officially supported for "swappiness" and it defines a

Re: Signature of the allow_migrate database router.

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

Re: status of 1.8 release blockers

If it's the only release blocker left and the fix is difficult, I think we could issue a beta release without it. I think the worst case is that you'll get some duplicate bug reports from testers. On Tuesday, February 17, 2015 at 10:06:27 AM UTC-5, Markus Holtermann wrote: > > So, it turns out t

Re: status of 1.8 release blockers

@Tim I believe it's quite easy actually, I've fixed my original patch and it's just waiting to be reviewed. It's available at https://github.com/django/django/pull/4071. However, it's a very rare bug and I only encountered it in the tests when working on another issue, not in any real project.

Re: Signature of the allow_migrate database router.

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

Re: Feature proposal: Conditional block tags

After looking at this, there's nothing special about blocks compared to any other node. They could just as well be evaluated at render time. Here's a branch that implements this change: https://github.com/prestontimmons/django/compare/conditional-blocks?expand=1 Before returning blocks into blo

Re: Signature of the allow_migrate database router.

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,

Re: Formalizing template loader and debug api's

Hi Preston, Thanks for your continued work on this and sorry for my slow answers. On 30 janv. 2015, at 03:24, Preston Timmons wrote: > The cache algorithm I added uses the origin object as a cache key. The "name" > attribute is used as part of the key value. Therefore, the underlying loader >

Re: Formalizing template loader and debug api's

On 17 févr. 2015, at 05:46, Preston Timmons wrote: > Even so, I think that can be handled with documentation. And an option to disable it. This is very easy to implement. > Do you think it's worth making an attempt to formalize this? Yes, I do. This is an independent follow-up to the big refa

Re: Formalizing template loader and debug api's

> > Thanks for your continued work on this and sorry for my slow answers. > No worries. I've been taking the time to get a better grasp of Django templates as a whole. > > Does that makes sense, or should I look for a way to incorporate that > > into LoaderOrigin? > > Looking at the implem

Re: Signature of the allow_migrate database router.

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

Re: Formalizing template loader and debug api's

> > Yes, I do. > > This is an independent follow-up to the big refactoring we’re talking > about, isn’t it? Cool. It depends. The cached loader is what I'm least happy with in my refactoring. This internal cache idea I think is simpler, more performant, and easier to understand. Adding it

Re: status of 1.8 release blockers

Today's update: Rrelease tomorrow seems unlikely -- let's target Friday and if we finish earlier, that's a bonus. #24307 Oracle Syncdb breaks trying to set NULL to column that already is NULL Owner: Sha

Re: Signature of the allow_migrate database router.

> 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

Re: Signature of the allow_migrate database router.

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.