Changes: * Drop Users.id_to_name. * Don't cache Users.name_to_id. * Replace calls to name_to_id with find_by_name when possible. * Don't autodefine creator_name in belongs_to_creator. * Don't autodefine updater_name in belongs_to_updater. * Instead manually define creator_name / updater_name only on models that need to return these fields in the api. id_to_name was cached to reduce the impact of N+1 query patterns in certain places, especially in api responses that return creator_name / updater_name fields. But it still meant we were doing N calls to memcache. Using `includes` to prefetch users avoids this N+1 pattern. name_to_id had no need be cached, it was never used in any performance- sensitive contexts. Avoiding caching also avoids the need to keep these caches consistent.
4 lines
808 B
Plaintext
4 lines
808 B
Plaintext
<% if post.visible? %>
|
|
<%= image_tag(post.file_url_for(CurrentUser.user), :width => post.image_width_for(CurrentUser.user), :height => post.image_height_for(CurrentUser.user), :id => "image", "data-original-width" => post.image_width, "data-original-height" => post.image_height, "data-large-width" => post.large_image_width, "data-large-height" => post.large_image_height, "data-tags" => post.tag_string, :alt => post.presenter.humanized_essential_tag_string, "data-uploader" => post.uploader.name, "data-rating" => post.rating, "data-flags" => post.status_flags, "data-parent-id" => post.parent_id, "data-has-children" => post.has_children?, "data-has-active-children" => post.has_active_children?, "data-score" => post.score, "data-fav-count" => post.fav_count, "itemprop" => "contentUrl") %>
|
|
<% end %>
|