I find this helpful as a rough hueristic for how engaged a user is -- if
they've never added an avatar, it's often the case that they never
really got further in to using the app than just registering a username.
Also, on one occassion, a user had an avatar that violated the instance
ToS, which would have been handy to see at a glance in this list.
Your reading status is shown across all editions of a work, so when you
change your status in relation to the edition you're currently reading,
it needs to invalidate the cached values for all editions of that work.
I originally set this for a very long timeout because this value should
be invalidated when it needs to be by the models, and if that worked
perfectly, this would reduce queries dramatically for books that show up
in ones feed frequently, but don't change status (for example, a book
you read and your friend is currently posting about). In practice, of
course, there are errors in invalidating this cache which leave this
value appearing extremely broken and it's next to impossible to fix.
This change makes each of the timeouts related to reading an hour, which
will still give performance benefit when browsing the site (especially
for loading the same book multiple times on a page), but resolve
naturally if the cache gets into a bad state.
This isn't what I need to be working on right now but it bugs me
immensely that the test coverage is at 89% and not 90% and this was the
lowest hanging fruit to get more coverage. Truly a me problem.
This is an edge case, and they OUGHT to have a user, but if the user was
deleted for a remote link, the field won't be able to resolve and the
user will be unset.
Right now notifications are a mix of post-save signals and clauses in
the save function of the model. I'm not actually sure which is better,
but I'm moving them to signals where it's straightforward to be
consistent.
