4 ms·
See step 6. The view is pulling the cache key straight from the domain model. It relies on being the informed as well about changes in its children to do that,
by dhh 15y ago
See step 6. The view is pulling the cache key straight from the domain model. It relies on being the informed as well about changes in its children to do that, which is what the setup in step 5 is about.
- Loic 15y agoDo am I wrong or you still hit the DB for each model object? But of course you save all the complex rendering (possibly SELECT for children) from the key, right?
- ludwigvan 15y agoNot necessarily I believe, that one can be cached and invalidated manually.
- dhh 15y agoYou hit the DB for the top-level. So in step 6, we'll always hit the db for the latest project, but we will not hit the db for the todolists or the todos of those todolists if the project cache is fresh. So you save the render plus any db calls that would be triggered as part of that render.
- hasenj 15y agoSo simple yet so brilliant! I can't believe I didn't think of this before. My initial reaction after I skimmed the post was "uhh, so you still hit the db? what's the point?" Thanks for sharing this! I definitely want to implement something similar for my future projects!