This is a followup to an earlier thread: Ruby on Rails query not working properly.
As noted, I have several listings. In particular, a listing has_many :spaces, through: :designations and has_many :amenities, through: :offerings.
I define filters to restrict the listings that get shown.
The two main ones are:
# 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
(Note that these reflect the solution indicated in the earlier thread.)
The first filter says: get all of the listings that have ALL of the selected amenities.
The second filter says: get all of the listings that match ANY of the selected space types.
But one issue remains. If I filter for space types 1 and 2 and amenities 1 and 2, I get listing A (which has space types 1 and 2 and amenity 2).
But I should presumably get [] since no listing has both amenities 1 and 2.
What is going on with these queries? Should they not be independent, but chainable?
Here is the output (I disabled the other filters for clarity):
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)
I have also tried adding raise 'test' in order to do some testing in the better_errors live shell. I discovered:
>> #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">]>
>>
Why is this happening and how can I fix it?
Any help would be greatly appreciated.
The issue is with how you are determining that all of the amenities have been matched.
When you are only joining the amenities then the count of the rows (prior to grouping) for a listing is the number of matched amenities, so the having clause does what you want.
When you join the spaces table too, then the number of rows (again prior to grouping) for a listing is the number of matches amenities times the number of matched rows. In your example there are 2 spaces and 1 amenity, so the count is 2 and your having clause is satisfied.
If instead of filtering on count(*) you filtered on count(distinct amenities.id) then you should be counting the number of amenity rows that were joined, which should produce the desired result.
I may have figured out the issue. I did the following in the console to test:
Set #listings = Listing.all.
Set #listings = #listings.joins(:amenities).where(amenities: { id: ['1', '2'].reject(&:blank?) }).group('listings.id').having('count(*) >= ?', ['1', '2'].reject(&:blank?).size).
This produces: => #<ActiveRecord::Relation []>, as desired.
I then checked to see what would happen if I were to do: #listings.joins(:spaces).
This produces: => #<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">]>, even though #listings was initially [].
So the problem has to do with the joins(:spaces) in the second filter.
In order to make sure that #listings remains [] in the event that that is the result of the first filter, I added the extra condition && #listings.present? to the second filter, yielding:
if params[:search][:space_ids].present? && params[:search][:space_ids].reject(&:blank?).size > 0 && #listings.present?
That extra condition prevents the second filter from being executed and returning results that should not be returned.
This feels like an ugly hack, and I would welcome better solutions, but it seems to work.
Related
I'm using will_paginate to paginate posts within a group.
A group might have many posts and I don't want to show all posts at once.
For some strange reason I noticed that a lot of posts are deleted from the database when I do #group.posts = paginated_posts as displayed in * groups_controller*.
I'm not doing save on #group, why are the posts deleted?
Tests first
69 it "Pagination – get one group and its posts" do
70 10.times { Fabricate(:post, group: #group, user: #user) }
71 puts "POST COUNT BEFORE #{#group.posts.count}"
72 # byebug
73 get group_path(#group, posts_per_page: 3)
74 puts "POST COUNT AFTER #{#group.posts.count}"
75 expect(response).to have_http_status(200)
76 expect(#group).to be_present
77 end
Output from the test
Groups
GET /group/:group_id?posts_per_page=10&posts_page=2
POST COUNT BEFORE 12
POST COUNT AFTER 3
groups_controller.rb
9 def show
10 paginated_posts = #group.posts.paginate(
11 page: params[:posts_page],
12 per_page: params[:posts_per_page] || 100000,
13 )
14 #group.posts = paginated_posts
15 render json: #group
16 end
The log
(0.3ms) RELEASE SAVEPOINT active_record_1
Started GET "/groups/33?posts_per_page=3" for 127.0.0.1 at 2018-09-18 12:52:13 +0000
Processing by GroupsController#show as HTML
Parameters: {"posts_per_page"=>"3", "id"=>"33"}
User Load (2.1ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2 [["id", "78913bd2-4c72-4c73-ba75-421e154c830b"], ["LIMIT", 1]]
Group Load (1.4ms) SELECT "groups".* FROM "groups" WHERE "groups"."id" = $1 LIMIT $2 [["id", 33], ["LIMIT", 1]]
Post Load (2.2ms) SELECT "posts".* FROM "posts" WHERE "posts"."group_id" = $1 LIMIT $2 OFFSET $3 [["group_id", 33], ["LIMIT", 3], ["OFFSET", 0]]
Post Load (0.3ms) SELECT "posts".* FROM "posts" WHERE "posts"."group_id" = $1 [["group_id", 33]]
(0.4ms) SAVEPOINT active_record_1
Comment Load (0.5ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = $1 [["post_id", 156]]
PostImage Load (0.3ms) SELECT "post_images".* FROM "post_images" WHERE "post_images"."post_id" = $1 [["post_id", 156]]
Post Destroy (0.3ms) DELETE FROM "posts" WHERE "posts"."id" = $1 [["id", 156]]
Comment Load (0.3ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = $1 [["post_id", 157]]
PostImage Load (0.3ms) SELECT "post_images".* FROM "post_images" WHERE "post_images"."post_id" = $1 [["post_id", 157]]
Post Destroy (0.3ms) DELETE FROM "posts" WHERE "posts"."id" = $1 [["id", 157]]
Comment Load (0.3ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = $1 [["post_id", 158]]
#group.posts = ... doesn't work the way you think it does. If you have a one-to-many relationship and you assign an array of associated records to the existing group object, the records set and remove the group.id foreign key immediately. No save is required.
So when you do
#group.posts = paginated_posts
The paginated posts are assigned to the association and all other records in the association are removed from the association. Instantly. They're not necessarily deleted, but they no longer belong to #post
You may want to change your #to_json ... perhaps add
attr_accessor :page_of_posts
And then in your controller
#group.page_of_posts = paginated_posts
And ensure page_of_posts is what's rendered in the json. Others may suggest a better way.
I am going back to refresh my Rails knowledge by watching some tutorials, and I came across where the tutorial rails app uses includes() on index.
def index
#books = Book.all
end
vs
def index
#books = Book.includes(:author, :genre)
end
As a side note, book belongs_to author and genre. Author has_many books and genre also has_many books.
When all is used, it looks like this when I refresh page:
Rendering books/index.html.erb within layouts/application
Book Load (1.4ms) SELECT "books".* FROM "books"
Author Load (0.3ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" = $1 LIMIT $2 [["id", 2], ["LIMIT", 1]]
Genre Load (0.3ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" = $1 LIMIT $2 [["id", 2], ["LIMIT", 1]]
Author Load (0.4ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" = $1 LIMIT $2 [["id", 1], ["LIMIT", 1]]
Genre Load (0.3ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" = $1 LIMIT $2 [["id", 3], ["LIMIT", 1]]
CACHE (0.0ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" = $1 LIMIT $2 [["id", 1], ["LIMIT", 1]]
CACHE (0.0ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" = $1 LIMIT $2 [["id", 3], ["LIMIT", 1]]
CACHE (0.0ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" = $1 LIMIT $2 [["id", 1], ["LIMIT", 1]]
CACHE (0.0ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" = $1 LIMIT $2 [["id", 2], ["LIMIT", 1]]
When includes is used, when I reload the page it shows:
Rendering books/index.html.erb within layouts/application
Book Load (0.4ms) SELECT "books".* FROM "books"
Author Load (0.5ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" IN (2, 1)
Genre Load (0.4ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" IN (2, 3)
I think this makes includes far more efficient than all because it hits the entire model database.
My question is, why do people still use all? Why not completely eradicate all and use includes from now on? Is there any situation where I would prefer to use all and not use includes? I am using Rails 5.0.1.
Let me talk a little bit about includes.
Suppose you need to get the user name of first five post. You quickly write the query below and go enjoy your weekend.
posts = Post.limit(5)
posts.each do |post|
puts post.user.name
end
Good. But let's look at the queries
Post Load (0.5ms) SELECT `posts`.* FROM `posts` LIMIT 5
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 2 LIMIT 1
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 2 LIMIT 1
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
1 query to fetch all posts and 1 query to fetch users for each post results in a total of 6 queries. Check out the solution below which does the same thing, just in 2 queries:
posts = Post.includes(:user).limit(5)
posts.each do |post|
puts post.user.name
end
#####
Post Load (0.3ms) SELECT `posts`.* FROM `posts` LIMIT 5
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` IN (1, 2)
There’s one little difference. Add includes(:posts) to your query, and problem solved. Quick, nice, and easy.
But don’t just add includes in your query without understanding it properly. Using includes with joins might result in cross-joins depending on the situation, and you don’t need that in most cases.
If you want to add conditions to your included models you’ll have to explicitly reference them. For example:
User.includes(:posts).where('posts.name = ?', 'example')
Will throw an error, but this will work:
User.includes(:posts).where('posts.name = ?', 'example').references(:posts)
Note that includes works with association names while references needs the actual table name.
I have 3 models, Portfolio, Stock and Transaction. When I'm in a portfolio show page I iterate through the portfolio's transactions and plot the stocks to show what I've bought.
When I load a portfolio show page the logs look something like this:
Started GET "/portfolios/1" for ::1 at 2016-09-24 02:15:32 -0400
Processing by PortfoliosController#show as HTML
Parameters: {"id"=>"1"}
Portfolio Load (0.6ms) SELECT "portfolios".* FROM "portfolios"
WHERE "portfolios"."id" = $1 LIMIT 1 [["id", 1]]
Transaction Load (2.0ms) SELECT "transactions".* FROM "transactions"
WHERE "transactions"."portfolio_id" = $1 [["portfolio_id", 1]]
Stock Load (1.7ms) SELECT "stocks".* FROM "stocks" WHERE "stocks"."id" = $1 LIMIT 1 [["id", 1]]
Stock Load (0.2ms) SELECT "stocks".* FROM "stocks" WHERE "stocks"."id" = $1 LIMIT 1 [["id", 6]]
Stock Load (0.2ms) SELECT "stocks".* FROM "stocks" WHERE "stocks"."id" = $1 LIMIT 1 [["id", 4]]
CACHE (0.0ms) SELECT "stocks".* FROM "stocks" WHERE "stocks"."id" = $1 LIMIT 1 [["id", 6]]
Stock Load (0.2ms) SELECT "stocks".* FROM "stocks" WHERE "stocks"."id" = $1 LIMIT 1 [["id", 2]]
Stock Load (0.2ms) SELECT "stocks".* FROM "stocks" WHERE "stocks"."id" = $1 LIMIT 1 [["id", 13]]
Stock Load (0.2ms) SELECT "stocks".* FROM "stocks" WHERE "stocks"."id" = $1 LIMIT 1 [["id", 9]]
Stock Load (0.2ms) SELECT "stocks".* FROM "stocks" WHERE "stocks"."id" = $1 LIMIT 1 [["id", 16]]
Stock Load (0.3ms) SELECT "stocks".* FROM "stocks"
Rendered transactions/_form.html.erb (19.1ms)
Rendered portfolios/show.html.erb within layouts/application (69.6ms)
Rendered application/_nav.html.erb (0.4ms)
Completed 200 OK in 128ms (Views: 90.5ms | ActiveRecord: 9.2ms)
My transaction, stock and portfolio models have these associations:
class Transaction < ActiveRecord::Base
belongs_to :portfolio
belongs_to :stock
end
class Stock < ActiveRecord::Base
has_many :transactions
end
class Portfolio < ActiveRecord::Base
belongs_to :user
has_many :transactions
has_many :stocks, through: :transactions
end
Within the show page, I loop through an instance portfolio and it's transactions using .each to grab the associated stock.
<% #portfolio.transactions.each do |trade| %>
In the portfolio controller the #portfolio is defined as #portfolio = Portfolio.find(params[:id]).
Is there a more efficient way to query the database (postgres) to retrieve the associated stock objects. Right now it's not a problem but I'm thinking of when people have a portfolio for a number of years and have hundreds of trades within the portfolio. Or should I be thinking of caching the results of a particular portfolio page using memcache or redis?
To avoid these queries you need to preload associations.
Something like this
#portfolio = Portfolio.preload(:stocks).find(params[:id])
This looks like an N + 1 queries problem, you can use eager_load or preload or includes to get rid of it:
#portfolio = Portfolio.eager_load(:stocks).find(params[:id])
I re-tooled my #portfolio object to #portfolio = Portfolio.includes(:transactions, :stocks).find(params[:id]).
Now I get all the stocks in one batch.
Parameters: {"id"=>"1"}
Portfolio Load (0.3ms) SELECT "portfolios".* FROM "portfolios"
WHERE "portfolios"."id" = $1 LIMIT 1 [["id", 1]]
Transaction Load (0.5ms) SELECT "transactions".* FROM "transactions"
WHERE "transactions"."portfolio_id" IN (1)
Stock Load (0.4ms) SELECT "stocks".* FROM "stocks" WHERE
"stocks"."id" IN (1, 6, 4, 2, 13, 9, 16)
Stock Load (0.3ms) SELECT "stocks".* FROM "stocks"
This is what I was trying to get. Since I'm using Rails 5 I'm not sure if eager_load or preload method are degraded. Includes seems like a more stable choice.
So I have a model that has an enum value like so:
class Connection < ActiveRecord::Base
enum request_status: { pending: 0, accepted: 1, rejected: 2, removed: 3 }
end
But, I have a params value that I want to set and do a where query on - something like this:
#connections = current_user.all_connections.where(request_status: params[:request_status])
current_user.all_connections returns an AR object (aka...it is also a query method with a where call).
The issue I am facing is that right now, the above query returns an empty collection. The reason I believe is that per the API docs in Rails:
Where conditions on an enum attribute must use the ordinal value of an
enum.
Given that params[:request_status] will look like this:
Parameters: {"request_status"=>"accepted"}
How would I modify that where query to reflect this? I know one other option is just to modify the parameter to be the ordinal value, rather than the string, but I am curious how I might achieve this with the string value rather than the ordinal value?
Edit 1
Here are the server logs:
Started GET "/connections?request_status=accepted" for 127.0.0.1 at 2016-01-04 20:23:08 -0500
Processing by ConnectionsController#index as HTML
Parameters: {"request_status"=>"accepted"}
User Load (2.7ms) SELECT "users".* FROM "users" WHERE "users"."id" = 3 ORDER BY "users"."id" ASC LIMIT 1
FamilyTree Load (1.7ms) SELECT "family_trees".* FROM "family_trees" WHERE "family_trees"."user_id" = $1 LIMIT 1 [["user_id", 3]]
Connection Load (2.0ms) SELECT "connections".* FROM "connections" WHERE "connections"."invited_user_id" = $1 ORDER BY "connections"."created_at" DESC [["invited_user_id", 3]]
Connection Load (1.8ms) SELECT "connections".* FROM "connections" WHERE "connections"."inviter_user_id" = $1 ORDER BY "connections"."created_at" DESC [["inviter_user_id", 3]]
Connection Load (2.2ms) SELECT "connections".* FROM "connections" WHERE (connections.invited_user_id = 3 OR connections.inviter_user_id = 3) AND "connections"."request_status" = 0 ORDER BY "connections"."created_at" DESC
Rendered connections/index.html.erb within layouts/connections (0.3ms)
Rendered connections/_header.html.erb (2.8ms)
Rendered shared/_navbar.html.erb (61.2ms)
Rendered shared/_footer.html.erb (3.2ms)
Rendered layouts/application.html.erb (1142.4ms)
Completed 200 OK in 1184ms (Views: 1155.5ms | ActiveRecord: 10.4ms)
Edit 2
This is the index action for that controller.
def index
params[:request_status] = "pending" if params[:request_status].nil?
#connections = current_user.all_connections.where(request_status: params[:request_status]).order(created_at: :desc).group_by { |c| c.created_at.to_date }
end
What's strange is that for every action that I click on that should send the correct request_status it still sends the SQL with request_status = 0.
I commented out the params[:request_status] = setter in the controller to see if that was doing it, but it wasn't it.
What could be causing this issue?
Here is another log for a different status:
Started GET "/connections?request_status=rejected" for 127.0.0.1 at 2016-01-04 21:30:29 -0500
Processing by ConnectionsController#index as HTML
Parameters: {"request_status"=>"rejected"}
User Load (2.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = 3 ORDER BY "users"."id" ASC LIMIT 1
FamilyTree Load (1.5ms) SELECT "family_trees".* FROM "family_trees" WHERE "family_trees"."user_id" = $1 LIMIT 1 [["user_id", 3]]
Connection Load (1.4ms) SELECT "connections".* FROM "connections" WHERE "connections"."invited_user_id" = $1 ORDER BY "connections"."created_at" DESC [["invited_user_id", 3]]
Connection Load (1.0ms) SELECT "connections".* FROM "connections" WHERE "connections"."inviter_user_id" = $1 ORDER BY "connections"."created_at" DESC [["inviter_user_id", 3]]
Connection Load (1.2ms) SELECT "connections".* FROM "connections" WHERE (connections.invited_user_id = 3 OR connections.inviter_user_id = 3) AND "connections"."request_status" = 0 ORDER BY "connections"."created_at" DESC
Rendered connections/index.html.erb within layouts/connections (0.2ms)
Rendered connections/_header.html.erb (2.5ms)
Rendered shared/_navbar.html.erb (60.3ms)
Rendered shared/_footer.html.erb (3.0ms)
Rendered layouts/application.html.erb (1103.8ms)
Completed 200 OK in 1130ms (Views: 1112.5ms | ActiveRecord: 7.3ms)
You can use Connection.request_statuses["pending"] to get 0.
So you can use string in your query like this:
#connections = current_user.all_connections.where(request_status: Connection.request_statuses[params[:request_status]])
I am using Spree 3.0.0, Spree Print Invoice gem and I have set it up in my gemfile using the branch: '3-0-stable'.
I have installed it with the command
bundle && exec rails g spree_print_invoice:install
I have a simple config/initializers/print_invoice.rb
Spree::PrintInvoice::Config.set(page_layout: :portrait,page_size: 'A4')
Spree::PrintInvoice::Config.set(print_buttons: 'invoice')
Spree::PrintInvoice::Config.set(store_pdf: true) # Default: tmp/order_prints
I have now in my admin configuration a Print Invoice Settings section as well as a print invoice button with each orders.
Here is the log when creating invoice:
Started GET "/admin/orders/R123456789.pdf?template=invoice" for ::1 at 2015-07-22 17:10:00 -0500
Processing by Spree::Admin::OrdersController#show as PDF
Parameters: {"template"=>"invoice", "id"=>"R123456789"}
Spree::Preference Load (0.3ms) SELECT "spree_preferences".* FROM "spree_preferences" WHERE "spree_preferences"."key" = $1 LIMIT 1 [["key", "spree/backend_configuration/locale"]]
Spree::User Load (0.5ms) SELECT "spree_users".* FROM "spree_users" WHERE "spree_users"."deleted_at" IS NULL AND "spree_users"."id" = $1 ORDER BY "spree_users"."id" ASC LIMIT 1 [["id", 6]]
(0.4ms) SELECT COUNT(*) FROM "spree_roles" INNER JOIN "spree_roles_users" ON "spree_roles"."id" = "spree_roles_users"."role_id" WHERE "spree_roles_users"."user_id" = $1 AND "spree_roles"."name" = $2 [["user_id", 6], ["name", "admin"]]
Spree::Order Load (0.6ms) SELECT "spree_orders".* FROM "spree_orders" WHERE "spree_orders"."number" = $1 ORDER BY "spree_orders"."id" ASC LIMIT 1 [["number", "R123456789"]]
Spree::Adjustment Load (0.5ms) SELECT "spree_adjustments".* FROM "spree_adjustments" WHERE "spree_adjustments"."adjustable_type" = 'Spree::Order' AND "spree_adjustments"."adjustable_id" IN (1) ORDER BY spree_adjustments.created_at ASC
Rendered text template (0.0ms)
Sent data (2.7ms)
Completed 200 OK in 18ms (Views: 2.5ms | ActiveRecord: 2.3ms)
The invoices are created into tmp/order_prints but they all are completely blanks. The pdf viewer of my browser is blocked on loading.
Anything I need to do in order to make it work?