You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm struggling to understand the exact implications of CACHALOT_FINAL_SQL_CHECK introduced in #199. It seems like by default omitting this check can cause invalidations to be missed. It also appears (at least from looking at the code) that it could cache results that are part of CACHALOT_UNCACHABLE_TABLES if it misses them.
In #199 (comment), @Andrew-Chen-Wang said it should be a flag because of its experimental nature. Is it still considered experimental, or can it be promoted to the default? I think it's currently a bit misleading that the default behavior forgoes correctness for performance.
The text was updated successfully, but these errors were encountered:
I think it's currently a bit misleading that the default behavior forgoes correctness for performance.
Primarily, still looking for feedback as sdolemelipone has found. The error found in #268 isn't really a surprise; I've seen it before multiple times in Django cachalot when updating for the latest Django version.
Description
I'm struggling to understand the exact implications of
CACHALOT_FINAL_SQL_CHECK
introduced in #199. It seems like by default omitting this check can cause invalidations to be missed. It also appears (at least from looking at the code) that it could cache results that are part ofCACHALOT_UNCACHABLE_TABLES
if it misses them.In #199 (comment), @Andrew-Chen-Wang said it should be a flag because of its experimental nature. Is it still considered experimental, or can it be promoted to the default? I think it's currently a bit misleading that the default behavior forgoes correctness for performance.
The text was updated successfully, but these errors were encountered: