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

johnny-cache django 1.3.1 with postgresql view: slow view is not being cached #48

Open
holisticode opened this issue Jan 18, 2014 · 3 comments

Comments

@holisticode
Copy link

OK this is not really an issue but a question.

Doing maintenance on a django 1.3.1 app. We took over from a different company.
In the settings.py file, I just discovered the following code:

# Models based on PostgreSQL views don't get their caches invalidated when
# their source tables are updated.
# FIXME: Disable caching of PostgreSQL views until we can figure out how to invalidate the view when its source tables are invalidated.
MAN_IN_BLACKLIST=['overview']

The app had johnny-cache 0.3.3 configured. I updated to the latest johnny-cache (1.4).

Does the above still apply??? Can I remove the overview view from the blacklist? Thing is, loading that view is reaaaaaalllyyyyy slow, so I think I know why now...

As soon as I commented out the blacklisted view, the application was flying...I really would love to leave it like this, but I need to understand if there are still any implications with invalidating cache on views.

@vishen
Copy link

vishen commented Jan 19, 2014

It depends how the source tables are being invalidated, if it's happening within the django application itself the tables will be invalidated, if it's happening outside the django application then the cache won't be invalidated unless explicitly told to, or until a save happens on the table from within the django application.

@jself
Copy link
Collaborator

jself commented Jan 21, 2014

vishen is correct, database views are updated outside of django so we can't really know inside of django (or johnny-cache) if a base table is invalidated that is used in a view. The reason we suggest the blacklist is because it's the most straightforward solution, since the database itself builds the view and we have no knowledge of how to invalidate it.

An alternative is if you want to write your own KeyHandler that builds a key for the view based on the source tables. There are other things in databases that fall into this as well, such as functions, etc. It was kind of a design decision to let the user handle those cases if they want them cached.

@holisticode
Copy link
Author

Thanks for the response guys. I don't know if you want to continue this conversation elsewhere, but I would welcome some support. In fact, I don't really understand the issue. Our view is read-only anyway. So why would there be a problem at all? When writes are being done they happen on the source tables directly, invalidating those caches right away. Would this affect the view caches as well?

If it IS an issue, can you point me to info about writing an own KeyHandler? I am an experienced web developer but fairly new to django. Thanks

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