As an opportunity to get my latest project so damn fast, I looked into key-based cache expiration, also known as the Russion Doll approach to caching.
There is something I don't understand. "You deal with dependency structures by tying the model objects together on > updates." So if you change a todo that belongs to a todolist that belongs to a > project, you update the updated_at timestamp on every part of the chain, > which will automatically then update the cache keys based on these objects Okay, so the hierarchy is project -> todolist -> todo. Then a single todo item, probably keeps track of its creator, right? In Rails it could be declared like this: class Project < ActiveRecord::Base end class Todolist < ActiveRecord::Base belongs_to :project, touch: true end class Todo < ActiveRecord::Base belongs_to :todolist, touch: true belongs_to :creator end # in app/views/project/show.html.erb <% cache project do %> <p>All my todo lists:</p> <%= render project.todolists %> <% end %> # in app/views/todolists/_todolist.html.erb <% cache todolist do %> <p><%= todolist.name %>:</p> <%= render todolist.todos %> <% end %> # in app/views/todo/_todo.html.erb <% cache todo do %> <p><%= todo.name %>(by <%= todo.creator.name %>)</p> <% end %> # This will not trigger todo.touch!, # which in turn does not trigger todo.todolist.touch! # and does not trigger todo.todolist.project.touch! todo.creator.update_attributes(name: 'John Doe') What do I need to change in order to make this process trivial to implement caching schemes and trust that I am never going to serve stale data? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/Ndt-tHnN5xsJ. For more options, visit https://groups.google.com/groups/opt_out.
