I'm having some trouble figuring out how to implement the SQL query where I can show the closest results (by calculated distance) first and paginate through them.
Class Location
belongs_to :student
geocoded_by :address
end
Class Student
has_one :location
has_one :school
end
Class School
belongs_to :student
end
now within SQL, I want to have a query that can go through the association Student.joins(:location) and find me the closest student from the perspective of the student who is searching. This is after specifying a specific school (so a subset of the overall Students)
For example, Joe goes to LSU and wants to be shown a list of the closest students that also go to LSU. But the distance is based on Joe's location so this will be different if Bob runs the same query.
So I know geocoder provides something like Location.nearbys(10) but what I'd really like to do is say
joe = Student.find("Joe")
closest_lsu_stdents_to_joe = Student.where("school = LSU").order(distance_to(joe)).paginate(:page => params[:page])
So I don't want to limit the search to a specified radius like nearbys does. I just want the database to calculate the distance between Joe and all the other students at LSU and return the closest ones first. And then Joe can go through all the results via the pagination.
Any help would be much appreciated. I'm using MySQL but open to other solutions.
Thanks a lot!!!
Related
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)
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.
I have a product model and a shop model. The relationship between two is shop has_many products and products belongs_to shop.
The shop model has two fields longitude and latitude used for distance calculation using geokit-rails. I have been successful in sorting shops by nearest distance to any given longitude and latitude using:
Shop.by_distance(origin:[params[:latitude], params[:longitude]]).sort_by{|s| s.distance_to([params[:latitude], params[:longitude]])}
The problem is with products. The products needs to be sorted according to nearest shop location as well. I have searched through and found out that a child model can be sorted from parents attributes like this:
Product.joins(:shop).order('shops.name')
The order function works only if supplied with model field. How can I sort products calculating shop distance.
Please help.
Have a look at the documentation on using :through - this should be exactly what you need.
So Product would look like:
class Product < ActiveRecord::Base
belongs_to :shop
acts_as_mappable through: :shop
...
end
And your query would be something like:
Product.joins(:shop).by_distance(origin: [params[:latitude], params[:longitude]])
If you already can filter and sort the Shop
#shops = Shop.by_distance(origin:[params[:latitude], params[:longitude]]).sort_by{|s| s.distance_to([params[:latitude], params[:longitude]])}
This will get all products from each shops according to the distance:
#closest_products = #shops.map(&:products)
If you want to weed out duplicate products, use this instead:
#closest_products = #shops.map(&:children).flatten.uniq
You may try an alternative method (I have not tested this):
#closest_products = Product.where(shop: #shops)
I have a rails application where I have following models -
City, Hotel, Restaurant, Park.
Associations are like this -
class City < ActiveRecord::Base
has_many :hotels
has_many :restaurants
has_many :parks
end
I want to find all cities that have at least one hotel or restaurant or Park.
How do I write single query to fetch such cities ?
For Rails 5, you can use like below
cities = City.includes(:hotels, :restaurants, :parks)
cities = ((cities.where.not(hotels: {id: nil})).or(cities.where.not(restaurants: {id: nil})).or(cities.where.not(parks: {id: nil})))
For lower version of rails , you need to use arel_table
Most appropriate solution would be using counter cache
Then you should be able to query like
City.where('hotels_count > 0 OR restaurants_count > 0 OR parks_count > 0')
P.S. This query can be re-written many ways e.g use .or method. Also, don't forget to reset cache counter if you have some data in associated tables.
The City model doesn't have any information about related stuff.
You need to select the data from hotel/park/etc.
Use AR's includes to find the all Cities with specified relations.
City.includes(:hotels, :restaurants, :parks)
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.