lepird/django-cacheops

Django-cacheops is a caching library for Django that provides automatic and manual queryset caching, function caching, and template fragment caching. It manages cache invalidation through event-driven updates, dependency tracking, and management commands. The system supports multiple backends including Redis, file, and in-memory caches, with a focus on transaction safety and performance.

The project is initialized with version 3.1.3, introducing a complete ORM caching solution for Django. This release includes automatic and manual queryset caching, function caching via decorators, and granular event-driven invalidation. Key features include transparent transaction handling, dog-pile prevention, and support for Redis, file, and simple in-memory caches. The package requires Django 1.7+, Python 2.7/3.3+, and Redis 2.6+. It also adds a new \CACHEOPS\_ENABLED\ setting to globally disable caching, a \cache\_read\ signal, and \.invalidated\_update()\ for cache invalidation on updates.

(repo-wide) · high confidence

The cacheops package has been refactored into distinct modules: cross.py handles Python 2/3 compatibility for pickling and hashing; jinja2.py adds Jinja2 template tags; redis.py implements a lazy Redis client with Lua scripts for cache operations; signals.py defines the cache\_read signal; transaction.py manages transaction state and SQL dirty tracking; tree.py converts query conditions to DNF; and simple.py provides the base cache implementations. The package now uses a Django AppConfig (CacheopsConfig) to install transaction support and cacheops on startup, replacing the previous manual initialization.

cacheops · high confidence

The cacheops Lua scripts for caching and invalidation have been rewritten. The new cache\_thing.lua script handles writing data to Redis using setex and manages dependency tracking by updating scheme sets and conjunction keys. The new invalidate.lua script processes invalidation requests by calculating conjunction keys from object fields, retrieving associated cache keys via sunion, and deleting them in chunks to handle large invalidation batches. This change introduces a more robust mechanism for cache invalidation and dependency tracking, addressing previous issues with empty queries and bulk invalidation.

cacheops/lua · medium confidence

The cacheops template tags have been refactored to support both older and newer versions of Django. The code now attempts to import the 'TagHelperNode' and 'parse\_bits' from 'django.template.library', falling back to 'django.template.base' for older versions. Additionally, the 'decorator\_tag' method now explicitly accepts a 'takes\_context' argument, allowing template tags to access the template context. A new 'invalidate\_fragment' function has been added to support cache invalidation for template fragments.

cacheops/templatetags · high confidence

The 'invalidate' management command now includes support for auto-created models, ensuring that cache invalidation applies to all models within a specified app, including those generated automatically. Additionally, the command's usage syntax has been updated to explicitly show the new capability for invalidating entire apps, specific models, or particular instances. A new 'cleanfilecache' command was also added to allow users to clean the file-based cache directory.

cacheops/management · high confidence

Added a comprehensive test suite for the cacheops library, including models, fixtures, and test cases covering query caching, invalidation, and transaction support. Also added a benchmarking framework to measure performance of common operations like pickle/unpickle, cache hits/misses, and object invalidation.

tests · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 57 → 57 (+0.4)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 95 (-4.8)
• Architecture 92 → 95 (+3.4)
• Maturity 43 → 43 (+0.0)
• Readiness 50 → 55 (+5.2)
• Security 76 → 76 (+0.0)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• No exposed public API
• Test reliability not included
• dormant codebase — no living knowledge left to concentrate

• Documentation: no architecture or design documentation (README.rst)
• HackComment (cacheops/query.py)
• HackComment (cacheops/query.py)
• HackComment (cacheops/transaction.py)
• HackComment (tests/tests.py)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• No ADRs found
• No dependency advisory monitoring
• TodoComment (cacheops/jinja2.py)
• TodoComment (cacheops/query.py)
• TodoComment (cacheops/query.py)
• TodoComment (cacheops/query.py)
• TodoComment (cacheops/query.py)
• …and 6 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

lepird/django-cacheops was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.