That would be ideal. In this case however, we have a variety of roles (owner, manager, assistant manager, teacher, substitute teacher), all with different permissions. Isolating those roles would still be an improvement, except there is still behavior specific to whether a user is attached to the item in another, non-role-based way (like this specific person is the teacher of a class, so they can check it out). So the user goes in the cache key.
Still, employees interact with the schedule repeatedly throughout the day, and items on the schedule can be shared between daily/weekly/individual/all-employee views, so even at the user level caching pays off.
Any thoughts on the lambda use? I haven't gotten any comments yet (here or on Twitter) indicating that anyone else has used it. I also can't tell whether the usage is really, really officially supported (Good: specifically approved via PR! Bad: Not documented anywhere outside of the PR).
I've never seen this lambda version of the cache key. The Rails collection cache code is quite easy to read. This is the line from github that gets your lambda - and if you don't provide one, they create a default one!
I usually create a wrapper object that implements a cache_key method to do the key generation. It also is then used inside the partial, so it's a little more noticable when you use data that isn't part of the cache key
For your case, you can do more in here for a complicated case
I've had object IDs and 4-5 booleans or enums in my cache key before now. Having 30 possible variants is still better than having 1 per user (unless you have only 30 users, in which case you may have optimized too soon)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That would be ideal. In this case however, we have a variety of roles (owner, manager, assistant manager, teacher, substitute teacher), all with different permissions. Isolating those roles would still be an improvement, except there is still behavior specific to whether a user is attached to the item in another, non-role-based way (like this specific person is the teacher of a class, so they can check it out). So the user goes in the cache key.
Still, employees interact with the schedule repeatedly throughout the day, and items on the schedule can be shared between daily/weekly/individual/all-employee views, so even at the user level caching pays off.
Any thoughts on the lambda use? I haven't gotten any comments yet (here or on Twitter) indicating that anyone else has used it. I also can't tell whether the usage is really, really officially supported (Good: specifically approved via PR! Bad: Not documented anywhere outside of the PR).
I've never seen this lambda version of the cache key. The Rails collection cache code is quite easy to read. This is the line from github that gets your lambda - and if you don't provide one, they create a default one!
github.com/rails/rails/blob/b378bd...
I usually create a wrapper object that implements a
cache_keymethod to do the key generation. It also is then used inside the partial, so it's a little more noticable when you use data that isn't part of the cache keyFor your case, you can do more in here for a complicated case
I've had object IDs and 4-5 booleans or enums in my cache key before now. Having 30 possible variants is still better than having 1 per user (unless you have only 30 users, in which case you may have optimized too soon)