Question

这是对早期帖子的跟进：Ruby on Rails query not working properly。

如上所述，我有几个列表。特别是列表has_many :spaces, through: :designations和has_many :amenities, through: :offerings。

我定义过滤器以限制显示的列表。

两个主要的是：

# filter by amenities
if params[:search][:amenity_ids].present? && params[:search][:amenity_ids].reject(&:blank?).size > 0
  @listings = @listings.joins(:amenities).where(amenities: { id: params[:search][:amenity_ids].reject(&:blank?) }).group('listings.id').having('count(*) >= ?', params[:search][:amenity_ids].reject(&:blank?).size)
end

# filter by space type
if params[:search][:space_ids].present? && params[:search][:space_ids].reject(&:blank?).size > 0
  @listings = @listings.joins(:spaces).where('space_id IN (?)', params[:search][:space_ids].reject(&:blank?)).uniq
end

（请注意，这些反映了早期帖子中指出的解决方案。）

第一个过滤器显示：获取包含所有选定设施的所有商家信息。

第二个过滤器说：获取与所选空间类型匹配的所有列表。

但仍有一个问题。如果我过滤空间类型1和2以及设施1和2，我会列出A（其中包含空间类型1和2以及设施2）。

但我应该得到[]，因为没有列表同时包含1号和2号设施。

这些查询是怎么回事？它们不应该是独立的，而是可链接的吗？

这是输出（为清晰起见，我禁用了其他过滤器）：

Started GET "/listings/search?utf8=%E2%9C%93&search%5Baddress%5D=London%2C+United+Kingdom&search%5Bprice_min%5D=0&search%5Bprice_max%5D=1000.0&search%5Bprice_lower%5D=0&search%5Bprice_upper%5D=1000&search%5Bsize_min%5D=0&search%5Bsize_max%5D=1000&search%5Bsize_lower%5D=0&search%5Bsize_upper%5D=1000&search%5Bspace_ids%5D%5B%5D=1&search%5Bspace_ids%5D%5B%5D=2&search%5Bspace_ids%5D%5B%5D=&search%5Bamenity_ids%5D%5B%5D=1&search%5Bamenity_ids%5D%5B%5D=2&search%5Bamenity_ids%5D%5B%5D=&search%5Bsort_by%5D=Distance&commit=Apply+Filters" for ::1 at 2015-10-31 14:25:58 +0000
  ActiveRecord::SchemaMigration Load (0.4ms)  SELECT "schema_migrations".* FROM "schema_migrations"
Processing by ListingsController#search as HTML
  Parameters: {"utf8"=>"✓", "search"=>{"address"=>"London, United Kingdom", "price_min"=>"0", "price_max"=>"1000.0", "price_lower"=>"0", "price_upper"=>"1000", "size_min"=>"0", "size_max"=>"1000", "size_lower"=>"0", "size_upper"=>"1000", "space_ids"=>["1", "2", ""], "amenity_ids"=>["1", "2", ""], "sort_by"=>"Distance"}, "commit"=>"Apply Filters"}
   (1.5ms)  SELECT MAX("listings"."price") FROM "listings"
   (0.6ms)  SELECT MAX("listings"."size") FROM "listings"
  Listing Load (4.4ms)  SELECT  DISTINCT "listings".* FROM "listings" INNER JOIN "offerings" ON "offerings"."listing_id" = "listings"."id" INNER JOIN "amenities" ON "amenities"."id" = "offerings"."amenity_id" INNER JOIN "designations" ON "designations"."listing_id" = "listings"."id" INNER JOIN "spaces" ON "spaces"."id" = "designations"."space_id" WHERE "amenities"."id" IN (1, 2) AND (space_id IN ('1','2')) GROUP BY listings.id HAVING count(*) >= 2 LIMIT 24 OFFSET 0
  Image Load (0.5ms)  SELECT  "images".* FROM "images" WHERE "images"."listing_id" = $1  ORDER BY "images"."id" ASC LIMIT 1  [["listing_id", 1]]
  Space Load (0.6ms)  SELECT "spaces".* FROM "spaces" INNER JOIN "designations" ON "spaces"."id" = "designations"."space_id" WHERE "designations"."listing_id" = $1  [["listing_id", 1]]
  Rendered listings/_map_infowindow.html.erb (56.1ms)
  Rendered listings/_price_slider.html.erb (0.7ms)
  Rendered listings/_size_slider.html.erb (0.6ms)
  Space Load (0.4ms)  SELECT "spaces".* FROM "spaces"
  Amenity Load (0.4ms)  SELECT "amenities".* FROM "amenities"
  Rendered scripts/_checkbox_toggle.html.erb (0.5ms)
  Rendered listings/_search_filters.html.erb (75.5ms)
   (0.4ms)  SELECT "spaces"."name" FROM "spaces" INNER JOIN "designations" ON "spaces"."id" = "designations"."space_id" WHERE "designations"."listing_id" = $1  [["listing_id", 1]]
  CACHE (0.0ms)  SELECT  "images".* FROM "images" WHERE "images"."listing_id" = $1  ORDER BY "images"."id" ASC LIMIT 1  [["listing_id", 1]]
  User Load (0.7ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1  [["id", 3]]
  Avatar Load (0.7ms)  SELECT  "avatars".* FROM "avatars" WHERE "avatars"."user_id" = $1  ORDER BY "avatars"."id" ASC LIMIT 1  [["user_id", 3]]
  Rendered listings/_listing_grid.html.erb (80.8ms)
   (3.1ms)  SELECT DISTINCT COUNT(DISTINCT "listings"."id") AS count_id, listings.id AS listings_id FROM "listings" INNER JOIN "offerings" ON "offerings"."listing_id" = "listings"."id" INNER JOIN "amenities" ON "amenities"."id" = "offerings"."amenity_id" INNER JOIN "designations" ON "designations"."listing_id" = "listings"."id" INNER JOIN "spaces" ON "spaces"."id" = "designations"."space_id" WHERE "amenities"."id" IN (1, 2) AND (space_id IN ('1','2')) GROUP BY listings.id HAVING count(*) >= 2
  Rendered scripts/_map.html.erb (2.9ms)
  Rendered scripts/_shuffle.html.erb (0.3ms)
  Rendered listings/search.html.erb within layouts/application (178.7ms)
  Rendered layouts/_head.html.erb (475.7ms)
  Rendered scripts/_address_autocomplete.html.erb (0.3ms)
  Rendered listings/_search_address.html.erb (13.7ms)
  User Load (0.4ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = $1  ORDER BY "users"."id" ASC LIMIT 1  [["id", 3]]
   (0.5ms)  SELECT DISTINCT "conversations"."id" FROM "conversations" WHERE (sender_id = 3 OR recipient_id = 3)
   (0.5ms)  SELECT DISTINCT "messages"."conversation_id" FROM "messages" WHERE ("messages"."user_id" != $1) AND "messages"."read" = $2  [["user_id", 3], ["read", "false"]]
  CACHE (0.0ms)  SELECT  "avatars".* FROM "avatars" WHERE "avatars"."user_id" = $1  ORDER BY "avatars"."id" ASC LIMIT 1  [["user_id", 3]]
  Rendered layouts/_navbar.html.erb (32.5ms)
  Rendered scripts/_fade_error.html.erb (0.4ms)
  Rendered scripts/_transparent_navbar.html.erb (0.3ms)
Completed 200 OK in 1045ms (Views: 688.6ms | ActiveRecord: 30.6ms)

我还尝试添加raise 'test'以便在better_errors live shell中进行一些测试。我发现了：

>> @listings
=> #<ActiveRecord::Relation []>
>> @listings = @listings.joins(:spaces).where('space_id IN (?)', params[:search][:space_ids].reject(&:blank?)).uniq
=> #<ActiveRecord::Relation [#<Listing id: 1, title: "Test 1", address: "New Inn Passage, London WC2A 2AE, UK", latitude: 51.5139664, longitude: -0.1167323, size: 1000, min_lease: 1, price: #<BigDecimal:7f89ec245c98,'0.1E4',9(18)>, description: "Test 1", user_id: 3, state: "public", created_at: "2015-10-30 17:37:04", updated_at: "2015-10-30 17:37:04">]>
>>

为什么会发生这种情况，我该如何解决？

非常感谢任何帮助。

Answer 1

我可能已经弄明白了这个问题。我在控制台中进行了以下测试：

设置@listings = Listing.all。
设置@listings = @listings.joins(:amenities).where(amenities: { id: ['1', '2'].reject(&:blank?) }).group('listings.id').having('count(*) >= ?', ['1', '2'].reject(&:blank?).size)。

根据需要产生=> #<ActiveRecord::Relation []>。

然后我检查了如果我这样做会发生什么：@listings.joins(:spaces)。

这会产生：=> #<ActiveRecord::Relation [#<Listing id: 1, title: "Test 1", address: "New Inn Passage, London WC2A 2AE, UK", latitude: 51.5139664, longitude: -0.1167323, size: 1000, min_lease: 1, price: #<BigDecimal:7ffcb02ce890,'0.1E4',9(18)>, description: "Test 1", user_id: 3, state: "public", created_at: "2015-10-30 17:37:04", updated_at: "2015-10-30 17:37:04">]>，即使@listings最初是[]。

所以问题与第二个过滤器中的joins(:spaces)有关。

为了确保@listings在第一个过滤器的结果中保持[]，我将额外条件&& @listings.present?添加到第二个过滤器，产生：

if params[:search][:space_ids].present? && params[:search][:space_ids].reject(&:blank?).size > 0 && @listings.present?

该额外条件阻止执行第二个过滤器并返回不应返回的结果。

这感觉就像一个丑陋的黑客，我会欢迎更好的解决方案，但似乎有效。

Answer 2

问题在于您如何确定所有设施都已匹配。

当您只加入设施时，列表的行数（分组前）是匹配设施的数量，因此having子句可以满足您的需求。

当您加入空格表时，列表的行数（再次分组之前）是匹配设施数与匹配行数之比。在您的示例中，有2个空格和1个舒适度，因此计数为2并且您的having子句已满足。

如果您在count(*)上过滤count(distinct amenities.id)而不是过滤，那么您应该计算已加入的设施行数，这应该会产生所需的结果。

Ruby on Rails查询产生意外结果

2 个答案: