Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify and consider changing the default value of CACHALOT_FINAL_SQL_CHECK #266

Open
danlamanna opened this issue Sep 4, 2024 · 2 comments

Comments

@danlamanna
Copy link
Contributor

danlamanna commented Sep 4, 2024

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 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.

@sdolemelipone
Copy link

It appears some queries may fail with CACHALOT_FINAL_SQL_CHECK=True; see #268.

@Andrew-Chen-Wang
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants