johnny-cache icon indicating copy to clipboard operation
johnny-cache copied to clipboard

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

Open holisticode opened this issue 11 years ago • 3 comments

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.

holisticode avatar Jan 18 '14 00:01 holisticode

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.

vishen avatar Jan 19 '14 22:01 vishen

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.

jself avatar Jan 21 '14 17:01 jself

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

holisticode avatar Jan 27 '14 03:01 holisticode