Opened 15 years ago
Closed 14 years ago
#13835 closed (wontfix)
enhancements in django.db.models to get info about additional tables
| Reported by: | fetzig | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 1.2 |
| Severity: | Keywords: | cache, johnny-cache | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
hi,
would like to see this patch in django. why? i'm trying to explain...without being to verbose...
i'm using django-johnny-cache (automatically caches results of querysets).
the concept is pretty simple (still more simplified):
- create cache key: table name + md5 hash of the db query (and its params).
- get/set cache works without any additional configuration in the code.
- update/insert/delete: invalidate all keys relating to this table (problem is: there is more than one table...)
when creating select statements which aggregate data of multiple tables the cache is not working correctly. => it doesn't invalidate all invalid cache keys. => you get old data :(
there is a fix for that, but it includes patching django
please have a look at this patch (attached). its totally backward compatible. just adds a table variable/property on some places. it looks ok for me...
link to johnny-cache issue http://bitbucket.org/jmoiron/johnny-cache/issue/7/use-subselect-tables-in-query-cache-key
thanks for feedback.
feel free to ask for more info.
kthxby,
klemens
Attachments (1)
Change History (2)
by , 15 years ago
| Attachment: | django-trunk-rev13294-for-johnny-cache.patch added |
|---|
comment:1 by , 14 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
| Triage Stage: | Unreviewed → Accepted |
according to johnny-cache author this has been resolved now in johnny-cache:
from the cited issue page: http://bitbucket.org/jmoiron/johnny-cache/issue/7/use-subselect-tables-in-query-cache-key
"This is fixed for Django 1.2.x in r124:66db10d95f72 and for Django 1.1.x in r125:d2cdde498f99 without resorting to patching Django. The 1.2.x fix should work for all future versions and across all database backends; if you use 1.1.x and a non-OSS database backend like Oracle or MS SQL, testing would be appreciated."