Hi, thanks for giving it a look. The PR are based on existing tickets so these are not my ideas. The relevant ticket <https://code.djangoproject.com/ticket/16774> for the backtracking URL contains valuable information about its benefits and why the author requested the feature. The idea is to "provide a way to pass control back to the URL router to try the remaining routes" if a certain route matched at first but doesn't want to handle this request and want to pass the control to another view -- see this comment <https://github.com/wagtail/wagtail/issues/6083#issuecomment-635267442> for an example of issue it would solve in reality --
Le jeudi 6 mai 2021 à 19:32:59 UTC+2, f.apo...@gmail.com a écrit : > Hi, > > I took a quick glance (literally just that) at the pull requests. I do > like the one that offers a way to abort early inside a prefix -- this is a > nice optimization and as well might open interesting options for > specialized catch all views. I am not convinced about the backtracking PR, > which problems does this solve in reality? What does this mean for features > like atomic requests -- it is still just one request after all… > > Cheers, > Florian > > On Wednesday, May 5, 2021 at 7:21:01 PM UTC+2 atd...@gmail.com wrote: > >> Ok I see better. >> Talking about efficiency, I take this opportunity to link here the >> following draft PR I made: Backtracking URL Resolver >> <https://github.com/django/django/pull/14343> and Provide ability to >> abort URL resolution early <https://github.com/django/django/pull/14342>, >> which, if implemented in the right way, may help make URL resolving more >> efficient and more flexible too. >> >> I understand that you may not have time to review or maybe this is not >> something you are planning to put into Django right now, but I would be >> very happy to have any feedback on it! >> >> Le mercredi 5 mai 2021 à 17:19:43 UTC+2, f.apo...@gmail.com a écrit : >> >>> On Thursday, April 29, 2021 at 4:23:57 PM UTC+2 atd...@gmail.com wrote: >>> >>>> In both cases however, the current check being done in the >>>> process_response method for the CommonMiddleware(here >>>> <https://github.com/django/django/blob/4ab3ef238edfa7c7b7c2c4420c7ae5b722bde121/django/middleware/common.py#L105-L108>) >>>> >>>> seems irrelevant to me unless I am missing *something*. >>>> >>> >>> You are most likely not missing anything and we also noticed that when >>> fixing the admin enumeration stuff. But we did not get around to fixing it >>> yet. That said, I think doing this in process_response would be preferable >>> over doing it in process_request so the extra checks when the URL is valid >>> (the common case) are reduced. Resolving URLs can take a bit, especially >>> when the urlconf is long and as such I'd like to get that check out of the >>> "hot" code path. Only doing the redirect in the case of a failing resolve >>> in the first place would probably make this more efficient. >>> >>> Cheers, >>> Florian >>> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/41821059-b9a5-433b-b08d-78e3d99d84dcn%40googlegroups.com.
