Demystifying cache in Doctrine ORM
summary
Explains concrete levers: Doctrine ORM metadata cache via opcache files speeds startup, query cache stores DQL→SQL translations, result cache holds full result sets with TTL, and second-level cache with read-only / non-strict read/write / read-write modes handles entity, collection and query regions and performs invalidation. Recommends Redis for caches, namespace per deployment plus cache warmup to avoid a stampede, warns about distributed lock limits and gives versions: Doctrine 2.6.1 requires PHP 7.1 and Doctrine 3 is being rewritten.
AI-written summary · about
chapters (13)
- 0:00Intro
- 0:40Why Doctrine
- 2:28Maintainability
- 5:52Concurrency
- 7:22Doctrine
- 9:59Entity Manager
- 11:11Unit of Work
- 12:13The Big Bowl of Mud
- 13:47Hydration
- 16:43External API
- 22:13Query
- 25:21Second level cache
- 30:10Query cache
related talks
53mHow Doctrine Caching Can Skyrocket Your Application
59mDoctrine ORM Good Practices and Tricks
42mSymfony Cache: a premium recipe to fast apps
01h 01mPHP Opcache Explained
59mHow much database abstraction do I need?
23mSf Cache Component: Speed Up Your App with a New Cache Layer
25mHow We Prepared Data: ORM and All That
40mDoctrine: More Than Just an ORM