I am implementing an availability model nested within a listing. Its for a rental app.
class Listing
has_many :availabilities, dependent: :destroy
end
class Availability
belongs_to :listing
end
availabilities table has start and end date columns.
I am writing a query through search form to find listings where availabilities are present and the date given in the form lies in between start and end dates fo those availabilities.
My query in a class method looks like:
def self.search(params)
date = params[:date]
listingsids = Availability.where('startdate <= ?', date).where('enddate >= ?', date).pluck('listing_id')
products = Listing.where(id: listingsids)
end
However i feel this is not efficient. I wish I can write Listing.joins(:availability) and then use it but rails won't allow it. I can only join the other way which will give me a relation with availability objects and I want listings i.e. parent resource.
How can I make it more efficient and reduce number of queries I am doing?
Will appreciate your help :)
You should be able to use joins on listing to get you availablity relations, joins works using the relation name, not the model name, so instead of joins(:availability) you should be using joins(:availabilities). Something like this should work and use just a single query for your case:
Listing.joins(:availablities).where('availability.startdate <= ?', date).where('availability.enddate >= ?', date)
notice that joins uses the relation name joins(:availabilities) but the string in the where uses the table name where('availability.startdate <=?', date)
Related
I have the following active record models:
class Catalog < ActiveRecord::Base
has_and_belongs_to_many :customers
end
class Customer < ActiveRecord::Base
has_and_belongs_to_many :catalogs
end
Now in my index, i want to list all customers sorted like this:
first the ones who already are member of the catalog, then all the others.
I have tried something like this:
#customers = Customer.all.joins('LEFT JOIN catalogs_customers ON catalogs_customers.customer_id = customers.id').order('catalogs_customers.catalog_id DESC, customers.company_name ASC')
That is near to my goal but i got all the customers who are member of a catalog (whatever it is) and then all the other customers.
Your question is a tiny bit unclear, but I can't comment to ask more, so I'll do my best regardless.
It sounds like you want to list all customers with priority given to those associated with one specific catalog, but your code samples don't tell us how you plan on setting that. I'll assume that you have an instance variable #catalog_id. Then you want to provide a condition on your join where you only select catalogs_customers with that catalog_id. So try something like:
#customers = Customer.all.joins('LEFT JOIN catalogs_customers ON catalogs_customers.customer_id = customers.id').
.where(catalogs_customers: { catalog_id: #catalog_id }).
order('catalogs_customers.catalog_id DESC, customers.company_name ASC')
Hope that helps.
Hello I had given query
refund1 = Spree::Order.joins(:refunds).group('currency').sum(:total)
=> {"USD"=>#<BigDecimal:7f896ea15ed8,'0.17641E4',18(18)>, "SGD"=>#<BigDecimal:7f896ea15d98,'0.11184E3',18(18)>, "EUR"=>#<BigDecimal:7f896ea15ca8,'0.1876E3',18(18)>}
2.2.1 :212 >
refund1 = Spree::Order.joins(:refunds).group('currency').count
=> {"USD"=>2, "SGD"=>1, "EUR"=>2}
refund1.each do |k,v| refund1[k]=[v,refund2[k]] end
=> {"USD"=>[2, #<BigDecimal:7f896f1d83a0,'0.17641E4',18(18)>], "SGD"=>[1, #<BigDecimal:7f896f1d3fa8,'0.11184E3',18(18)>], "EUR"=>[2, #<BigDecimal:7f896f1d3aa8,'0.1876E3',18(18)>]}
refund1 = Spree::Order.joins(:refunds).group('currency').sum(refund.amount)
this is not working i need to sum refund amount not an order total
I need to fetch date also i.e on 02-08-2017 two orders refunded of 100USD
Please guide me how to fetch that.
Rails/ActiveRecord are good for relatively easy groupings, and you can group on multiple attributes instead of just the currency, but applying a function to one of the grouped values and returning multiple aggregations (sum and count) requires some effort.
It will also not be very performant unless you either start specifying SQL fragments in your select clause select("date_trunc(...), currency, sum(...), count(...)") or start using Arel (which to me always looks more complex than SQL with very few redeeming benefits).
I (because I am quite a SQL-ey person) would be tempted here to place a database view in the system that defines the aggregations that you want at the grouping level you want, and reference that in Rails through a model.
Create View spree_refund_day_currency_agg as select ....;
... and ...
class Spree::RefundDayCurrencyAgg < ActiveRecord::Base
def self.table_name
spree_refund_day_currency_agg
end
def read_only?
true
end
belongs_to ....
end
You can then access your aggregated data in the Rails environment as if it were a magically maintained set of data (similar to a materialised view, without the materialisation) in a totally flexible manner (as intended with an RDBMS) using logic defined in Rails.
For example, with scopes defined in the model
def self.bad_day_in_canada
where(currency: CANADA_CURR)
end
Not to everyone's taste though, I'm sure.
Currently I am developing a small book rating app, where users can rate and comment on books.
Of course I have a book model:
class Book < ActiveRecord::Base
has_many :ratings
end
and a rating model:
class Rating < ActiveRecord::Base
belongs_to :book
end
The "overall rating value" of a rating object is calculated by different rating categories (e.g. readability, ... ). Furthermore the overall rating of one book should be calculated by all given ratings.
Now the question I am asking myself: Should I calculate/query the overall rating for every book EVERYTIME someone visits my page or should I add a field to my book model where the overall rating is (periodically) calculated and saved?
EDIT: The "calculation" I would use in this case is a simple average determination.
Example: A Book has about 200 ratings. Every rating is a composition of 10 category ratings. So I want to determine the average of one rating and in the end of all 200 ratings.
If the averaging of those ratings is not computationally expensive (i.e. doesn't take a long time), then just calculate it on-the-fly. This is in keeping with the idea of not prematurely optimsing (see http://c2.com/cgi/wiki?PrematureOptimization).
However, if you do want to optimise this calculation then storing it on the book model and updating the calculation on rating writes is the way to go. This is known as "caching" the result. Here is some code that will cache the average rating in the database. (There are other ways of caching).
class Book < ActiveRecord::Base
has_many :ratings, after_add :update_average_rating
def update_average_rating
update_attribute(:average_rating, average_rating)
end
def average_rating
rating_sum / ratings.count
end
def rating_sum
ratings.reduce(0) {|sum, rating|
sum + rating.value # assuming rating model has a value attribute
}
end
end
class Rating < ActiveRecord::Base
belongs_to :book
end
Note: the above code assumes the presence of an average_rating column on your book table in your database. Remember to add this column with a migration.
DB
The most efficient (although not conventional) way is to use db-level ALIAS columns, allowing you to calculate the AVG or SUM of the rating with each book call:
#app/models/book.rb
class Book < ActiveRecord::Base
def reviews_avg category
cat = category ? "AND `category` = \"#{category}\"" : ""
sql = "SELECT AVG(`rating`) FROM `reviews` WHERE `book_id` = #{self.id} #{cat})
results = ActiveRecord::Base.connection.execute(sql)
results.first.first.to_f
end
end
This would allow:
#book = Book.find x
#book.reviews_avg # -> 3.5
#book.reviews_avg "readability" # -> 5
This is the most efficient because it's handled entirely by the DB:
Rails
You should use the average functionality of Rails:
#app/models/book.rb
class Book < ActiveRecord::Base
has_many :ratings do
def average category
if category
where(category: category).average(:rating)
else
average(:rating)
end
end
end
end
The above will give you the ability to call an instance of a #book, and evaluate the average or total for its ratings:
#book = Book.find x
#book.reviews.average #-> 3.5
#book.reviews.average "readability" #-> 5
--
You could also use a class method / scope on Review:
#app/models.review.rb
class Review < ActiveRecord::Base
scope :avg, (category) -> { where(category: category).average(:rating) }
end
This would allow you to call:
#book = Book.find x
#book.reviews.avg #-> 3.5
#book.reviews.avg "readability" #-> 5
Association Extensions
A different way (not tested) would be to use the proxy_association.target object in an ActiveRecord Association Extension.
Whilst not as efficient as a DB-level query, it will give you the ability to perform the activity in memory:
#app/models/book.rb
class Book < ActiveRecord::Base
has_many :reviews do
def avg category
associative_array = proxy_association.target
associative_array = associative_array.select{|key, hash| hash["category"] == category } if category
ratings = associative_array.map { |a| a["rating"] }
ratings.inject(:+) / associative_array.size #-> 35/5 = 7
end
end
end
This would allow you to call:
#book = Book.find x
#book.reviews.avg # -> 3.5
#book.reviews.avg "readability" # -> 5
There is no need at all to recalculate the average overall rating for every page visit since it only will change when somebody actually rates the book. So just use a field AVG_RATING or something like this and update the value on every given rating.
Have you consider to use a cached version of the rating.
rating = Rails.cache.fetch("book_#{id}_rating", expires_in: 5.minutes) do
do the actual rating calculation here
end
In most cases you can get averages simply by querying the database:
average = book.reviews.average(:rating)
And in most cases its not going to be expensive enough that querying per request is going to be a real problem - and pre-mature optimization might be a waste of time and resources as Neil Atkinson points out.
However when the cost of calculation becomes an issue there are several approaches to consider which depend on the nature of the calculated data.
If the calculated data is something with merits being a resource on its own you would save it in the database. For example reports that are produced on a regular bases (daily, monthly, annual) and which need to be query-able.
Otherwise if the calculated data has a high "churn rate" (many reviews are created daily) you would use caching to avoid the expensive query where possible but stuffing the data into your database may lead to an excessive amount of slow UPDATE queries and tie up your web or worker processes.
There are many caching approaches that compliment each other:
etags to leverage client side caching - don't re-render if the response has not changed anyways.
fragment caching avoids db queries and re-rendering view chunks for data that has not changed.
model caching in Memcached or Redis can be used to avoid slow queries.
low level caching can be used to store stuff like averages.
See Caching with Rails: An overview for more details.
In my rails app I have few related models for example:
Event
has_many :comments
has_many :attendents
has_many :requests
What I need is to order by 'created_at' but not only main model (Event) but also related models, so I will display on top of the list event with most recent activity i.e.: comments, attendents, requests
So if Event date is newer than any comment, request or attendent date this event will be on top.
But if there is an event with newer comment this one will be on top etc.
How should I implement such ordering?
EDIT
db is mysql
Thanks
I would place a column on the event for last_activity, and maintain it by touching from the associated models.
The alternative is to order by using a join or subquery against the other tables, which is going to require a database query that will be much less efficient than simply ordering by last_activity descending.
Event
.select("events.*")
.joins("LEFT OUTER JOIN comments ON comments.event_id = events.id")
.joins("LEFT OUTER JOIN attendents ON attendents.event_id = events.id" )
.joins("LEFT OUTER JOIN requests ON requests.event_id = events.id")
.group("events.id")
.order("GREATEST(events.created_at,
MAX(comments.created_at),
MAX(attendents.created_at),
MAX(requests.created_at)) DESC")
If I understand your question correctly, something like this
Firstly add this to your Models in question:
default_scope order('created_at DESC')
Then I would do some grouping:
#comments = Comment.all
#comments_group = #comments.group_by { |c| c.event}
And in your view you'll be able to loop through each block:
#comments_group.each do |event, comment|
- event.name
comment.each do|c|
- c.body
I did not test this but it should give you an idea.
Right now, I'm working on a simple app. It requires to get the associated objects ordered by the date that they we're added to the object. For that, I want to order them based on the pivot-table's id.
My app looks a bit like this:
class Product < ActiveRecord::Base
has_and_belongs_to_many :users
end
class User < ActiveRecord::Base
has_and_belongs_to_many :products
end
However, when a user wants to buy a product, I would add a new relation into the pivot table courses_users. When I then run #product.users, I will get them back in the order the users where created, not added as the relation.
I've tried creating a query scope, but it didn't work. I also tried to create a order on the has_and_belongs_to_many, as such:
has_and_belongs_to_many :users, order: 'course_users.id ASC'
But none of that seemed to work, no ORDER statement could be found in the logs.
Add the created_at field to your table.
rails g migration AddTimestampsToCourseUsers created_at:datetime
then you can
#product.users.order "course_users.created_at ASC"