I’v found out that the view still communicates with the database (17 Queries):
不需要这17个额外查询.因为我已经从控制台测试了控制器查询,并且它成功地收集了部分_dropdown(在5个查询中)所需的所有数据,而没有任何进一步的数据库通信.
这是我的控制器中的query,它是为了避免N 1问题. (包括视图中调用的所有变量)
这是下拉代码：
- @messages.each do |message|
%li.conversation-container
%a{href: conversation_path(message.conversation_id)}
- if message.sender != current_user
.notification-avatar{style: "background: url(#{message.sender.avatar_url}); background-size: contain; background-repeat: no-repeat; background-position: 50% 50%;"}
- else
- other_participant = message.conversation.conversation_participants.select{|p| p.user_id != current_user.id }.first.user
.notification-avatar{style: "background: url(#{other_participant.avatar_url}); background-size: contain; background-repeat: no-repeat; background-position: 50% 50%;"}
%p
%strong
- if message.sender != current_user
= message.sender.name
- else
= other_participant.name
%br
- if message.sender == current_user
%i.fa.fa-mail-reply-all
= truncate(message.body,length: 25)
.time
= time_ago_in_words(message.created_at)
ago
- if @messages.count == 0
%li
.empty-state-text-white
No messages
控制台输出：
2.0.0-p353 :006 > ms = Message.dropdown_for(3).all Message Load (1.2ms) SELECT "messages".* FROM "messages" LEFT JOIN messages AS m ON messages.id != m.id AND m.conversation_id = messages.conversation_id AND messages.created_at < m.created_at INNER JOIN conversation_participants AS cp ON cp.conversation_id = messages.conversation_id AND cp.user_id = 3 WHERE (m.id IS NULL) ORDER BY cp.seen,cp.updated_at DESC LIMIT 5 User Load (0.7ms) SELECT "users".* FROM "users" WHERE "users"."id" IN (6,4,5) Conversation Load (0.4ms) SELECT "conversations".* FROM "conversations" WHERE "conversations"."id" IN (4,2,3) ConversationParticipant Load (0.2ms) SELECT "conversation_participants".* FROM "conversation_participants" WHERE "conversation_participants"."conversation_id" IN (4,3) User Load (0.6ms) SELECT "users".* FROM "users" WHERE "users"."id" IN (6,3,5) => [#<Message id: 8,body: "saSasa",sender_id: 6,conversation_id: 4,sent: true,attachment_id: nil,attachment_type: nil,created_at: "2014-11-17 16:05:40",updated_at: "2014-11-17 16:05:40">,#<Message id: 2,body: "asdnas dagsdashjdg jahs d",sender_id: 4,conversation_id: 2,created_at: "2014-11-17 11:32:36",updated_at: "2014-11-17 11:32:36">,#<Message id: 6,body: "SADASD A DSA ",sender_id: 5,conversation_id: 3,created_at: "2014-11-17 13:43:34",updated_at: "2014-11-17 13:43:34">] 2.0.0-p353 :007 > ms.first.conversation.conversation_participants.select{|cp| cp.user_id != 3}.first.user => #<User id: 6,first_name: "Ddsfsd",middle_name: nil,last_name: "Fsdfsd",photo: nil,email: "1@k.com",encrypted_password: "$2a$10$5sgib2DbQ1ctMrTzD3AJ0uV18hhiC5Ei1wcfE7MSAvRU...",reset_password_token: nil,reset_password_sent_at: nil,remember_created_at: nil,sign_in_count: 1,current_sign_in_at: "2014-11-17 15:27:06",last_sign_in_at: "2014-11-17 15:27:06",current_sign_in_ip: "127.0.0.1",last_sign_in_ip: "127.0.0.1",confirmation_token: nil,confirmed_at: "2014-11-17 15:27:48",confirmation_sent_at: "2014-11-17 15:27:05",unconfirmed_email: nil,Failed_attempts: 0,unlock_token: nil,locked_at: nil,authentication_token: nil,created_at: "2014-11-17 15:27:05",updated_at: "2014-11-17 15:27:48",slug: "ddsfsd_fsdfsd"> 2.0.0-p353 :008 > ms.count => 3
如何在没有目的的情况下阻止这些查询运行？
解决方法
在调试可能导致此问题的每个可能因素之后.
我试着在我的development.rb中将config.cache_classes设置为true.这成功删除了所有额外的查询.
我得出结论(默认情况下)在未缓存类时,不会为任何模型加载模式.换句话说,当config.cache_classes设置为false时,将为每个请求加载每个模型的模式作为单独的查询.
这是一个类似的问题column_definitions method being called before and after every single SQL statement on PostgreSQL.
*结论
cache_classesshould be set tofalseindevelopmentenvironment.
Ignore the extra internal queries from postgresql connection adapter
loading the schema for each model since it not going to affect your
production environment (production hasconfig.cache_classesset to
true).
原文地址：https://www.jb51.cc/ruby/268461.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
