I have several objects that all have an approved field.
What would be the best way to implement a scope to use across all models?
For example, I have a sighting object and a comment object. They both have to be approved by an admin before being availalbe to the public.
So how can I create a scope that returns comment.approved as well as sighting.approved respectively without repeating it on each model? Is this where concerns comes into play?
While just declaring a scope in each model is fine if you just want the scoping functionality. Using an ActiveSupport::Concern will give you the ability to add additional methods as well if that's something you think is going to happen. Here's an example:
# /app/models/concerns/approved.rb
module Approved
extend ActiveSupport::Concern
included do
default_scope { where(approved: false) }
scope :approved, -> { where(approved: true) }
end
def unapprove
update_attribute :approved, false
end
end
class Sighting < ActiveRecord::Base
include Approved
end
class Comment < ActiveRecord::Base
include Approved
end
Then you can make calls like Sighting.approved and Comment.approved to get the appropriate list of approved records. You also get the unapprove method and can do something like Comment.approved.first.unapprove.
In this example, I've also included default_scope which will mean that calls like Sighting.all or Comment.all will return only unapproved items. I included this just as an example, it may not be applicable to your implementation.
Although I've noticed the scope pulled from the concerns needs to be the last scope when concatenating scopes. I'm not quite sure why.
Comment.existing.approved
When I tried it as:
Comment.approved.existing
It failed silently.
And I take that back. I was migrating older code and using scopes with conditions instead of lambdas. When I replaced :conditions the scope order no longer mattered.
scope :existing, -> { where("real = 1") }
replaced
scope :existing, :conditions => "real = 1"
Related
I have two models
class Project
has_one: user
end
class User
# Attributes
# active: Boolean
# under_18: Boolean
def can_work?
active? && under_18 == false
end
end
The logic for can_work?
if active is true and under_18 is false then they can work
I want to do something like this but it's not possible
Project.all.joins(:user).where('users.can_work? = ?', false)
Essentially what I'm looking for is to find all users who can't work
I know I can use Scope, but copying the logic that I specified above in scope is confusing.
Here's the scenario that I'm looking for
active | under_18
------------------
T T = F
T F = T
F T = F
F F = F
Thanks
As per Sergio Tulentsev's answer, you can't do it. But if you want it DRY so badly you can use scopes.
Scope definition alt. 1:
scope :can_work, -> { where active: true, under_18: false }
scope :cant_work, -> { where.not id: User.can_work.pluck(:id) }
Scope definition alt. 2:
scope :can_work, ->(t=true) { where(active: t).where.not(under_18: t) }
New can_work? method
def can_work?
User.can_work.pluck(:id).include?(id)
end
Now you can call:
Project.joins(:user).merge(User.cant_work)
Or
Project.joins(:user).merge(User.can_work(false))
PS. Good luck with the speed.
Try
Project.joins(:users).where(user: {under_18: <Bool>, active: <Bool>})
Insert the Boolean values (true or false) that you want in place of <Bool>s above.
Source
Side note
If users are workers then I suggest changing names in your schema to look like:
workers
id
project_id
under_18
active
1
1
TRUE
TRUE
...
...
...
...
projects
id
title
1
"lorem"
...
...
So the associations would be
class Project
has_one :worker
end
class Worker
belongs_to :project
end
And the query would then look like
Project.joins(:workers).where(worker: {under_18: <Bool>, active: <Bool>})
I think it makes more sense from a naming standpoint.
That is since users are oftentimes regarded as the owners in association relationships (i.e. a project would belong to a user, and a user would have many projects). Just a quick side suggestion.
Answer: Scope
Scopes are custom queries defined in Rails model inside method named scope
A scope can have two parameters, the name of the scope and lambda which contains the query.
Something like:
class User < ApplicationRecord
scope :is_active, -> { where(active: true) }
scope :under_18, -> { where(under_18: true) }
end
Scope returns ActiveRecord::Relation object. So scopes can be chained with multiple scopes like,
User.is_active.under_18
The scope is nothing but a method same as class methods. The only difference is that you get a guarantee of getting ActiveRecord::Relation as an output of scope. This helps you to write specific code and helps to reduce errors in the code.
Default Scope:
You can also add a default scope on any model which is implicitly applied to every query made on the respective model.
Be cautious while using this though as this might cause unpredictable results.
For example:
class User < ApplicationRecord
default_scope :is_active, -> { where(active: true) }
scope :under_18, -> { where(under_18: true) }
end
In the above case, User.first will return the first user who is active.
Benefits of Scope
Testable - The separate scopes are more testable now as they now follow the Single Responsibility Principle
Readable
DRY - Combining multiple scopes allows you not to repeat the code
I've got a Rails application that is multi-tenant. Every model has an account_id, belongs to an account, and has a default scope to a current account id:
class Derp < ApplicationRecord
default_scope { where(account_id: Account.current_id) }
belongs_to :account
end
This works well and I've used this pattern in production in other apps (I understand that default scopes are frowned upon, but this is an accepted pattern. See: https://leanpub.com/multi-tenancy-rails).
Now here's the kicker - I have one client (and potentially more down the line, who knows), who wants to run the software on their own server. To solve this, I simply made a Server model with a type attribute:
class Server < ApplicationRecord
enum server_type: { multitenant: 0, standalone: 1 }
end
Now on my multi-tenant server instance, I simply make one Server record and set the server_type to 0, and on my standalone instance I set it to 1. Then I've got some helper methods in my application controller to help with this, namely:
class ApplicationController < ActionController::Base
around_action :scope_current_account
...
def server
#server ||= Server.first
end
def current_account
if server.standalone?
#current_account ||= Account.first
elsif server.first.multitenant?
#current_account ||= Account.find_by_subdomain(subdomain) if subdomain
end
end
def scope_current_account
Account.current_id = current_account.id
yield
rescue ActiveRecord::RecordNotFound
redirect_to not_found_path
ensure
Account.current_id = nil
end
end
This works, but I've got large record sets that I'm querying on this particular standalone client (70,000 records). I've got an index on the account_id, but it took my main customers table from 100ms to 400ms on my development machine.
Then I realized: standalone servers really don't need to concern themselves with the account id at all, especially if it is going to affect performance.
So really all I've got to do is make this line conditional:
default_scope { where(account_id: Account.current_id) }
I'd like to do something like this:
class Derp < ApplicationRecord
if Server.first.multitenant?
default_scope { where(account_id: Account.current_id) }
end
end
But obviously that syntax wrong. I've seen some other examples on Stack Overflow for conditional scopes, but none seem to work with a conditional statement based on a completely separate model. Is there a way to accomplish something like that in Ruby?
EDIT: Kicker here that I just realized is that this will only solve the speed issue for the one standalone server, and all the multi-tenant accounts will still have to deal with querying with the account_id. Maybe I should focus on that instead...
I would avoid using default_scope as I've been bitten by it in the past. In particular, I've had places in an application where I want to definitely have it scoped, and other places where I don't. The places where I want the scoping typically end up being controllers / background jobs and the places where I don't want / need it end up being the tests.
So with that in mind, I would opt for an explicit method in the controller, rather than an implicit scoping in the model:
Whereas you have:
class Derp < ApplicationRecord
if Server.first.multitenant?
default_scope { where(account_id: Account.current_id) }
end
end
I would have a method in the controller called something like account_derps:
def account_derps
Derp.for_account(current_account)
end
Then wherever I wanted to load just the derps for the given account I would use account_derps. I would then be free to use Derp to do an unscoped find if I ever needed to do that.
Best part about this method is you could chuck your Server.first.multitenant? logic here too.
You mention another problem here:
This works, but I've got large record sets that I'm querying on this particular standalone client (70,000 records). I've got an index on the account_id, but it took my main customers table from 100ms to 400ms on my development machine.
I think this is most likely due to a missing index. But I don't see the table schema here or the query so I don't know for certain. It could be that you're doing a where query on account_id and some other field, but you've only added the index to the account_id. If you're using PostgreSQL, then an EXPLAIN ANALYZE before the query will point you in the right direction. If you're not sure how to decipher its results (and sometimes they can be tricky to) then I would recommend using the wonderful pev (Postgres EXPLAIN Visualizer) which will point you at the slowest parts of your query in a graphical format.
Lastly, thanks for taking the time to read my book and to ask such a detailed question about a related topic on SO :)
Here's my solution:
First, abstract the account scoping stuff that any account scoped model will have to an abstract base class that inherits from ApplicationRecord:
class AccountScopedRecord < ApplicationRecord
self.abstract_class = true
default_scope { where(account_id: Account.current_id) }
belongs_to :account
end
Now any model can cleanly be account scoped like:
class Job < AccountScopedRecord
...
end
To solve the conditional, abstract that one step further into an ActiveRecord concern:
module AccountScoped
extend ActiveSupport::Concern
included do
default_scope { where(account_id: Account.current_id) }
belongs_to :account
end
end
Then the AccountScopedRecord can do:
class AccountScopedRecord < ApplicationRecord
self.abstract_class = true
if Server.first.multitenant?
send(:include, AccountScoped)
end
end
Now standalone accounts can ignore any account related stuff:
# Don't need this callback on standalone anymore
around_action :scope_current_account, if: multitenant?
# Method gets simplified
def current_account
#current_account ||= Account.find_by_subdomain(subdomain) if subdomain
end
In one of my Rails models I have this:
class Project < ActiveRecord::Base
belongs_to :user
default_scope order("number ASC")
end
Now the problem is that I want each user to be able to set his or her default_scope individually. For example, a user A might want default_scope order("date ASC"), another one might want default_scope order("number DESC").
In my User table I even have columns to store these values: order_column and order_direction.
But how can I make the default_scope in the model dynamic?
Thanks for any help.
As #screenmutt said, default scopes are not meant to be data-driven, they are meant to be model driven. Since this scope is going to change according to each user's data I'd use a regular scope for this.
#fmendez answer is pretty good but it uses default scope which I just explained why it is not recommended using this method.
This is what I'd do in your case:
class Post < ActiveRecord::Base
scope :user_order, lambda { order("#{current_user.order_column} #{current_user.order_direction}")}
end
Also a very important thing to notice here is SQL injection: Since you are embedding current_user.order_column and current_user.order_direction inside your query, you MUST ensure that the user can only feed these columns into the database with valid data. Otherwise, users will be able to craft unwanted SQL queries.
You won't want to use default_scope. What you do what is regular scope.
class Post < ActiveRecord::Base
scope :created_before, ->(time) { where("created_at < ?", time) }
end
Scope | Ruby on Rails
You could do something like this:
def self.default_scope
order("#{current_user.order_column} #{current_user.order_direction}")
end
This should dynamically pick the values stored in the current_user's order_column and order_direction columns.
You can define a class method with whatever logic you require and set your default scope to that. A class method is identical to a named scope when it returns a relation,eg by returning the result of a method like order.
For example:
def self.user_ordering
# user ording logic here
end
default_scope :user_ordering
You may want to add a current_user and current_user= class methods to your User model which maintains the request user in a thread local variable. You would typically set the current user on your User model from your application controller. This makes current_user available to all your models for logic such as your sorting order and does it in a thread safe manner.
Let's say I have two models
class Client < ActiveRecord::Base
has_many :accounts
end
class Account < ActiveRecord::Base
belongs_to :client
end
Now, I want to have convenient method to access approved accounts(:approved => true).
What is better to use, and why?
has_many: approved_accounts, -> { where :approved => true } for Client model
or
scope: approved, -> { where :approved => true } for Account model
Short answer, It Depends. For Long answer, kindly read on...
Conditional associations allows us to Customize the query that ActiveRecord will use to fetch the association. Use when you are sure that this condition is permanent & you will never-ever need access to data that doesn't fit the conditional(atleast not in this model) as Conditional associations are APPLIED to every query to ActiveRecord does to the association from that particular model.
Scope It is basically, a class method for retrieving and querying objects. so what you are actually doing is defining the following method in your model.
class Client < ActiveRecord::Base
self.approved
where(:approved => true)
end
end
so scope is generally use to define short names for one or more regularly used query customization. But important difference is that scope is not auto-applied unless you use default_scope but conditional associations are auto-applied.
In your case, you want to show unapproved accounts in this model? If not, then use conditional association. Else use scope
According to me, the scope solution seems the better:
As you probably know, to get the approved accounts of a client, you can do: approved_accounts = client.accounts.approved which is not less legible than: approved_accounts = client.approved_accounts
So not many difference here. But if in the future you want the list of all approved accounts (for statistics or whatever), with the scope solution, a single approved_accounts = Account.approved will be enough. But if you choose the client side, it will be trickier to get (understand: you will have to use the Client model).
Just consider than being approved is a property of an Account more than a property of a Client and it should be clearer that the scope is the best solution.
Hope this clarifies things.
I have a situation where the behavior of an existing app is changing and it's causing me a major headache.
My app has Photos. Photos have a status: "batch", "queue", or "complete". All the existing Photos in the app are "complete".
99% of the time I need to only show complete photos, and in all of the existing codebase I need every call to Photos to be limited to only complete photos.
However, in the screens related to uploading and classifying photos I need to be able to fairly easily override that default scope to show batched or queued photos.
Like many others, I need to find a way to easily override the default scope in certain situations. I looked at these questions (1, 2) and they don't seem to answer what I'm looking for.
The code I wish worked is this:
class Photo < ActiveRecord::Base
...
default_scope where(:status=>'complete')
scope :batch, unscoped.where(:status=>'batch')
scope :queue, unscoped.where(:status=>'queue')
...
end
However, that doesn't work. I tried wrapping the scope methods in lambdas, and that didn't work either.
I realize default_scope comes with baggage, but if I can't use it with overrides then I'm looking at adding scope :complete ... and having to comb through every call to photos in my existing app and add .complete in order to filter unprocessed photos.
How would you solve this problem?
def self.batch
Photo.unscoped.where(:status=>"batch")
end
This thread is more authoritative: Overriding a Rails default_scope
I give it a shot. Lets say you want to remove a where clause from a default scope (and not just override it with another value) and keep associations you can try this:
class Photo < ActiveRecord::Base
default_scope where(:status => 'complete').where(:deleted_at => '').order('id desc')
def self.without_default_status
# Get the ActiveRecord::Relation with the default_scope applied.
photos = scoped.with_default_scope
# Find the where clause that matches the where clause we want to remove
# from the default scope and delete it.
photos.where_values.delete_if { |query| query.to_sql == "\"photos\".\"status\" = 'complete'" }
photos
end
end