4👍
The most difficult part is that you have to consider both directions at the same time when setting the order. I would say that’s a flaw in the design and I personally would opt for a separate request and response middleware order (so you wouldn’t need hacks like FetchFromCacheMiddleware and UpdateCacheMiddleware).
But… alas, it’s this way right now.
Either way, the idea of it all is that your request passes through the list of middlewares in top-down order for process_request and process_view. And it passes your response through process_response and process_exception in reverse order.
With UpdateCacheMiddleware this means that any middleware that changes the Vary headers in the HTTP request should come before it. If you change the order here than it would be possible for some user to get a cached page for some other user.
How can you find out if the Vary header is changed by a middleware? You can either hope that there are docs available, or simply look at the source. It’s usually quite obvious 🙂
2👍
One tip that can save your hair is to put TransactionMiddleware in such place on the list, in which it isn’t able to rollback changes commited to the database by other middlewares, which changes should be commited no matter if view raised an exception or not.
- [Django]-Why is __init__ module in django project loaded twice
- [Django]-Django: multiple models in one template using forms
- [Django]-How to show ALL keys through redis-cli?