-
Notifications
You must be signed in to change notification settings - Fork 3
Make use of bulk_create
to avoid scaling issues
#11
Comments
@tbrlpld I see the case when update is needed. |
@dest81 I understand the case you want to address. I am wondering though, what URL/slug will the page with id 2 have? Because on the client side, the redirect needs to be going from one URL to another. It seems like the case you are describing would create a redirect loop. URL of page 2 is This would happen unless Wagtails URL resolution first looks which page would be served and then serve that one and only look through the redirects if no page with the given URL is found. In this case though, we could delete the redirect as it is never used. This of course would be bad from a SEO perspective, because the search engine could have already received a 301 Permanent Redirect ( Maybe it should be prevented to create pages with URLs that match a permanent redirect? This does not seem to be a issue for this package, but rather for Wagtail itself. |
Also, for updates there is also |
Wagtail serves existing page first even if there is a redirect for with the same url
Agree it sounds reasonable on my opinion and as you said it's not an issue of this package. But I think it would be good to remove redirect in case if page with the same url is published. Then preventing creation of page with url which exists in redirects will be up to wagtail. |
I take it then that the update of the redirect is not necessary, since Wagtail will already serve the desired page (id = 2) at the original URL ( It could be considered to delete the redirect if there is a page served at the original URL. Though again, this also seems like more of a general way for how Wagtail deals with redirects. |
It was pointed out to me by Wagtail core developer @kaedroho that we should consider making use of Django's
bulk_create
to avoid scaling issues with the automatic redirects.We are currently using
create_or_update
(here and here).I was wondering if the update part of that method is ever needed. If we already have a redirect pointing from an old path to the page object then this should still point to the right page object, even it if its slug is changed again (or the page is moved). Please correct me if I am wrong. Might be worth adding a test to make sure this works.
In that case the redirect don't need updating, we could drop the update part and create only new redirects in an efficient manner.
The text was updated successfully, but these errors were encountered: