[GH-ISSUE #365] restructure templates so a 404 doesn't access the DB #279

New issue

Closed

opened 2026-02-26 10:30:29 +03:00 by kerem · 4 comments

kerem commented

2026-02-26 10:30:29 +03:00

Owner

Originally created by @ThomasWaldmann on GitHub (Sep 30, 2018).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/365

Originally assigned to: @ThomasWaldmann on GitHub.

In nsupdate.context_processors.update_ips, it calls requestion.session.save() causing a DB write - even if we just want to render a 404 page.

This should be way less heavy.

Originally created by @ThomasWaldmann on GitHub (Sep 30, 2018). Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/365 Originally assigned to: @ThomasWaldmann on GitHub. In `nsupdate.context_processors.update_ips`, it calls `requestion.session.save()` causing a DB write - even if we just want to render a 404 page. This should be way less heavy.

kerem closed this issue

2026-02-26 10:30:29 +03:00

kerem commented

2026-02-26 10:30:30 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Sep 30, 2018):

see #356 for an example.

@ThomasWaldmann commented on GitHub (Sep 30, 2018): see #356 for an example.

kerem commented

2026-02-26 10:30:31 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Oct 1, 2018):

see #367 for a workaround.

is there a way to know (in a context processor) for which template the context is being prepared?
then we could return early/empty if we know it is just an error template and not even try to save the session.

@elnappo ^

@ThomasWaldmann commented on GitHub (Oct 1, 2018): see #367 for a workaround. is there a way to know (in a context processor) for which template the context is being prepared? then we could return early/empty if we know it is just an error template and not even try to save the session. @elnappo ^

kerem commented

2026-02-26 10:30:31 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Oct 16, 2018):

I couldn't find a way for the context_processor to see for which template it is being used.

What we do have though is request.method and request.path_info.

Also, the context processors are ONLY invoked if a template is in fact rendered.
So our stuff at /nic/... won't invoke them because it does not use templates.

@ThomasWaldmann commented on GitHub (Oct 16, 2018): I couldn't find a way for the context_processor to see for which template it is being used. What we do have though is `request.method` and `request.path_info`. Also, the context processors are ONLY invoked if a template is in fact rendered. So our stuff at `/nic/...` won't invoke them because it does not use templates.

kerem commented

2026-02-26 10:30:32 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Oct 18, 2018):

i hopefully worked around the problem by using the file-based session store, so the session saves won't hammer the db.

for the error pages, i guess there is only one solution: not using templates, so the context processors won't get executed. note: even the default error pages use in-code templates, so they need to get overridden.

@ThomasWaldmann commented on GitHub (Oct 18, 2018): i hopefully worked around the problem by using the file-based session store, so the session saves won't hammer the db. for the error pages, i guess there is only one solution: not using templates, so the context processors won't get executed. note: even the default error pages use in-code templates, so they need to get overridden.

kerem referenced this issue

2026-02-26 10:31:30 +03:00

[PR #279] [MERGED] fix #278 #442