During my work on a faster implementation of the MenuRenderer, I came across the model
menu.models.MenuCache.
This models in my opinion doesn't make any sense at all, and could be dropped. It has been added in 2010 without
not more than one thread/process can for instance rebuild the menu tree. If that's the original intention, then the current implementation
however does not work as expected, one would have to use
SELECT FOR UPDATE to block the resource, ie. the chosen
cache-key. It's somehow weird, to use a relational database to block a resource inside a memory cache.
that we force django-CMS users to exclusively rely on Redis caching, rather than say memcached or other caching mechanisms.
Therefore my proposal is to completely drop that table and remove the code using it. It just makes harm, with no evident benefit.
The worst scenario which could happen (but happens anyway), is that two threads/processes compute the menu tree at the same
time and the later one wins in that sense, that it is the one which writes its computed data to the cache. So, that's not a real problem.
What do other core developers of django-CMS think about this proposal?
– Jacob