I have an admittedly ugly query to do, to find a particular role related to the current role. This line produces the correct result:
#person_event_role.event_role.event.event_roles.
joins(:mission_role).where(:mission_roles => {:title => 'Boss'}).
first.person_event_roles.first.person
(You can infer the associations from the plurality of those calls)
The only way to get this information requires a ton of knowledge of the structure of the database, but to remove the coupling... It would require filling in a bunch of helper functions in each step of that chain to give back the needed info...
I think the thing to do here is to create the helper functions where appropriate. I'm unclear what the beginning of your association chain is here, but I'd probably assign it a method #event that returns event_role.event. From there, an event has an #boss_role, or whatever makes sense semantically, and that method is
event_roles.joins(:mission_role).where(:mission_roles => {:title => 'Boss'}).first
Finally, also on the Event model, there's a #boss method, which gets
boss_roles.first.person_event_roles.first.person
So, your original query becomes
#person_event_role.event.boss
Each leg of the chain is then self-contained and easy to understand, and it doesn't require the beginning of your chain to be omniscient about the end of it. I don't fully comprehend the full reach of these associations, but I'm pretty sure that just breaking it into three or four model methods will give you the clean reading and separation of concerns you're looking for. You might even break it down further for additional ease of reading, but that becomes a question of style.
Hope that helps!
The following is by the original questioner
I think I followed this advice and ended up with:
#person_event_role.get_related_event_roles_for('Boss').first.filled_by.first
#person_event_role:
def get_related_event_roles_for(role)
event.event_roles_for(role)
end
def event
event_role.event
end
#event:
def event_roles_for(role)
event_roles.for_role(role)
end
#event_role:
scope :for_role, lambda {|role| joins(:mission_role).where(:mission_roles => {:title => role})}
def filled_by
person_event_roles.collect {|per| per.person}
end
Related
I'm using Rails 5. I have a model that looks like this
class CryptoIndexCurrency < ApplicationRecord
belongs_to :crypto_currency
end
I have a service method where I want to populate this table with records, which I do like so
CryptoIndexCurrency.delete_all
currencies.each do |currency|
cindex_currency = CryptoIndexCurrency.new({:crypto_currency => currency})
cindex_currency.save
end
The problem is the above is not very transactional, in as far as if something happens after the first statement, the "delete_all" will have executed but nothing else will have. What is the proper way to create a transaction here and equally as important, where do I place that code? Would like to know the Rails convention here.
I think you can just do:
CryptoIndexCurrency.transaction do
CryptoIndexCurrency.delete_all
CryptoIndexCurrency.create(currencies.map{ |c| {crypto_currency: c} })
end
If you are using Activerecord you can use the builtin transaction mechanism. Otherwise, one way would be to make sure you validate all your data and only save when everything is valid. Take a look at validates_associate and the like.
That said, if your process is inherently non validatable/nondeterministic (eg. you call external APIs to validate a payment) then the best is to ensure you have some cleaning methods that take care of your failure
If you have deterministic failures:
def new_currencies_valid?(currencies)
currencies.each do
return false if not currency.valid?(:create)
end
true
end
if new_currencies_valid?(new_currencies)
Currency.delete_all # See note
new_currencies.each(&:save)
end
A sidenote : unless you really understand what you are doing, I suggest calling destroy_all which runs callbacks on deletion (such as deleting dependent: :destroy) associations
I have two models, User and Account.
# account.rb
belongs_to :user
# user.rb
has_one :account
Account has an attribute name. And in my views, I was calling current_user.account.name multiple times, and I heard that's not the great of a way to do it. So I was incredibly swift, and I created the following method in my user.rb
def account_name
self.account.name
end
So now in my view, I can simply call current_user.account_name, and if the association changes, I only update it in one place. BUT my question is, do I test this method? If I do, how do I test it without any mystery guests?
I agree there is nothing wrong with current_user.account.name - while Sandi Metz would tell us "User knows too much about Account" this is kind of the thing you can't really avoid w/ Active Record.
If you found you were doing a lot of these methods all over the User model you could use the rails delegate method:
delegate :name, :to => :account, :prefix => true
using the :prefix => true option will prefix the method in the User model so it is account_name. In this case I would assume you could write a very simple unit test on the method that it returns something just incase the attribute in account would ever change your test would fail so you would know you need to update the delegate method.
There's nothing wrong with current_user.account.name
There's no difference between calling it as current_user.account.name, or making current_user.account_name call it for you
You're probably not calling current_user in the model, like you say
You should have a spec for it if you use it
Personally I see no good reason for any of this. Just use current_user.account.name.
If you are worrying about efficiency, have current_user return a user that joins account.
This is going to be a bit off-topic. So, apologies in advance if it's not interesting or helpful.
TL;DR: Don't put knowledge of your models in your views. Keep your controllers skinny. Here's how I've been doing it.
In my current project, I've been working to make sure my views have absolutely no knowledge of anything about the rest of the system (to reduce coupling). This way, if you decide to change how you implement something (say, current_user.account.name versus current_user.account_name), then you don't have to go into your views and make changes.
Every controller action provides a #results hash that contains everything the view needs to render correctly. The structure of the #results hash is essentially a contract between the view and the controller.
So, in my controller, #results might look something like {current_user: {account: {name: 'foo'}}}. And in my view, I'd do something like #results[:current_user][:account][:name]. I like using a HashWithIndifferentAccess so I could also do #results['current_user']['account']['name'] and not have things blow up or misbehave.
Also, I've been moving as much logic as I can out of controllers into service objects (I call them 'managers'). I find my managers (which are POROs) a lot easier to test than controllers. So, I might have:
# app/controllers/some_controller.rb
class SomeController
def create
#results = SomeManager.create(params)
if #results[:success]
# happy routing
else
# sad routing
end
end
end
Now, my controllers are super skinny and contain no logic other than routing. They don't know anything about my models. (In fact, almost all of my controller actions look exactly the same with essentially the same six lines of code.) Again, I like this because it creates separation.
Naturally, I need the manager:
#app/managers/some_manager.rb
class SomeManager
class << self
def create(params)
# do stuff that ends up creating the #results hash
# if things went well, the return will include success: true
# if things did not go well, the return will not include a :success key
end
end
end
So, in truth, the structure of #results is a contract between the view and the manager, not between the view and the controller.
DHH wrote an article advocating for the use of concerns. It seems like a good practice, and in a lot of cases, they work well with my app. There are several cases, however, where multiple models have similar but slightly different methods, such as:
def find_or_create_membership
user_membership = User::Membership.where(:group_id => self.group_id,
:user_id => self.invitee_id).first_or_create(:status => "invited")
end
and:
def find_or_create_membership
user_membership = User::Membership.where(:group_id => self.group_id,
:user_id => self.invitee_id).first_or_create(:status => "declined")
end
These methods are identical save that the first sets status to "invited" and the second to "declined". Is there a way I could pass an argument to these methods via a concern?
You might be interested in Paramix.
Never used it myself, though. Dunno, smells like a False-Good-Idea©.
I have a User model, which have voting methods. I want to write proxy methods for voting.
This is readable way:
def vote_up item
return false unless can? :vote, item
vote item, :up
end
def vote_down item
return false unless can? :vote, item
vote item, :down
end
And this is DRY way:
%w(up down).each do |vtype|
define_method "vote_#{vtype}" do |item|
return false unless can? :vote, item
vote item, vtype.to_sym
end
end
Which one is better and why?
Purely because OP seemed to like my comment, I'll put it as an answer:
Personally, considering you only have 2 methods here, and it's unlikely you'd ever add more (vote_sideways? vote_diagonally?) I would just go with the readable way. If you could potentially have many, many more though, I would go with the DRY way (because it becomes easily extendible) with a readable comment to explain to other developers (or to yourself later!).
Neither(sorry).
def vote_count(item,vtype)
return false unless can? :vote, item
vote item, vtype
end
Good luck
IMHO, in this case, readability trumps dry. It scans quickly, and is easily grokked. Having said that, if you start adding vote types the second approach may be more flexible. YMMV.
Both.
I'm with Anil; just pass in a type--meta-programming this as a first-resort is yucky.
That said, I am a fan of convenience methods--but they should call the generic method with the type.
This keeps the generated method concise--the real work is done in the generic method, but the API user still gets the same convenience methods.
I've got a nested resource of User Reading Lists (a User has_many Reading Lists). I'm trying to mock everything in my controller specs, but having trouble keeping it concise. Here's the before code for the #show action:
#reading_lists = mock("Reading lists")
#reading_lists.stub!(:find).with("1").and_return(#reading_list)
#user = mock_model(User, :reading_lists => #reading_lists)
User.stub!(:find).with("1").and_return(#user)
get :show, :user_id => "1", :id => "1"
which is testing:
def show
#user = User.find(params[:user_id])
#reading_list = #user.reading_lists.find params[:id]
end
This seems like a crazy amount of boilerplate - is there a better way to mock it out?
There is not a better way to mock it out, but you are right to note that this is a lot of boiler plate. The reason is that user.reading_lists.find is a Law of Demeter violation. Whether or not you view the Law of Demeter as important, mocking through violations of it is painful.
I'd recommend either using the real models or simplifying the interaction with the model. I can't really say how without seeing what you're trying to specify.