I have 4 clases, with an STI on Instance.
Workspace, Project, Task, Instance, (type1 < Instance) and (type2 < Instance).
With proper associations. (Workspace has_many projects, has_many task through projects, so on)
And I have this nested create (worked before implementing STI):
if (%w(type1 type2).include?(params[:type]))
sti_class = params[:type].classify.constantize
workspaces.find_by_name(name: w_name).
projects.where( name: p_name).first_or_create!.
tasks.where(name: t_name).first_or_create!.
sti_class.create()
now, that doesn't work, I can't figure out a way.
However, the following works, but I want to keep the nested create.
task= workspaces.find_by_name(name: w_name).
projects.where( name: p_name).first_or_create!.
tasks.where(name: t_name).first_or_create!
sti_class.create(task_id: task.id)
How can I keep the nested create?
The problem I could immediately deduce is that the sti_class method isn't defined in your Task model, as you're adding it to the method chain.
Don't really think you're following the best practice here, but to immediately resolve the issue, you should probably do something like:
if (%w(type1 type2).include?(params[:type]))
# depending on the association between the type(s) and the tasks,
# you'd need to either singularize or pluralize here, I'd assume
# task has many types, therefore pluralize
sti_class = params[:type].pluralize
# if you're already calling `find_by_name`, you don't need to pass
# the name option here anymore, but the name argument
workspaces.find_by_name(w_name).
projects.where(name: p_name).first_or_create!.
tasks.where(name: t_name).first_or_create!.
send(sti_class).create
Related
I'm working with a massive legacy code base, so I am looking for advice concerning this particular issue, please, not suggestions of better high-level implementations.
A simplified version of what I'm working with:
class Order < ActiveRecord::Base
has_many :line_items
#other stuff
def balance
#some definition
end
end
class LineItem < ActiveRecord::Base
belongs_to :order
#other stuff
end
module Concerns
module LineItems
module Aggregates
extend ActiveSupport::Concern
#stuff
def balance
#some other definition
end
end
end
end
Order has a method called 'balance,' and a module of LineItem also has a method called 'balance.' It seems that most of the time (in most places in the code base), when specific_line_item.balance is called, it used the method definition under the LineItem module, but there are a couple of places where it instead calls the method from Order.
Is there any way in Ruby/Rails to specify on method call which of these two I'd like to use? OR is there probably something else going on here because Ruby doesn't have method overloading, so the problem I'm describing here isn't possible?
All relevant cases where either method is called are coming from a line_item (i.e. specific_line_item.balance), so I would think it would always choose the method closer to home, rather than making the associative jump and calling Order's 'balance' method without being told to.
EDIT:
Thanks for the responses! It seems I wasn't clear enough with my question. I understand the difference between
Order.first.balance
and
LineItem.first.balance
and that the balance method being called is the one defined within the class for that object. In the situation I'm describing, I observed, in the actual live app environment, that at a place in the code where
LineItem.find(some_id).balance
was called it output not the result that would be computed by the LineItem 'balance' method, but the one from the Order class.
So I had hoped to learn that there's some ruby quirk that might have an object call an associate's method of the same name under some conditions, rather than it's own. But I'm thinking that's not possible, so there's probably something else going on under the covers specific to this situation.
Firstly, ActiveRecord::Concern can change a lot of behaviour and you've left out a lot of code, most crucially, I don't know where it's being injected, but I can make an educated guess.
For a Concern's methods to be available a given object, it must be include'd in the object's class's body.
If you have access to an instance of the Order object, at any point you can call the balance method:
order = Orders.last # grab the last order in your database
order.balance # this will call Order#balance
And if you have the Order then you can also get the LineItem:
order.line_items.first.balance # should call the Concerns:: LineItems::Aggregates#balance
You can open up a Rails console (with rails console) and run the above code to see if it works as you expect. You'll need a working database to get meaningful orders and balances, and you might need to poke around to find a completed order, but Ruby is all about exploration and a REPL is the place to go.
I'd also grep (or ag or ack) the codebase looking for calls to balance maybe doing something like grep -r "(^|\s)\w+\.balance" *, what you want to look for is the word before .balance, that is the receiver of the "balance" message, if that receiver is an Order object then it will call Order#balance and if it is a LineItem object then it will call Concerns:: LineItems::Aggregates#balance instead.
I get the feeling you're not familiar with Ruby's paradigm, and if that's the case then an example might help.
Let's define two simple Ruby objects:
class Doorman
def greet
puts "Good day to you sir!"
end
end
class Bartender
def greet
puts "What are you drinking?"
end
end
Doorman and Bartender both have a greet method, and which is called depends on the object we call greet on.
# Here we instantiate one of each
a_doorman = Doorman.new
a_bartender = Bartender.new
a_doorman.greet # outputs "Good day to you sir!"
a_bartender.greet # outputs "What are you drinking?"
We're still using a method called greet but the receiver is what determines which is called.
Ruby is a "message passing language" and each "method" is not a function but it's a message that is passed to an object and handled by that object.
References
How to use concerns in Rails 4
http://api.rubyonrails.org/classes/ActiveSupport/Concern.html
http://guides.rubyonrails.org/command_line.html#rails-console
I added a variable in config/application.rb:
config.available_account_types = %w(SystemAccount CashAccount DemandAccount LiabilityAccount CreditCardAccount)
And generated some scopes in model account.rb:
for t in Mypurse::Application.config.available_account_types
scope t.underscore.pluralize.to_sym, -> {where(type: t)}
end
But when I try all of them, Account.system_accounts, Account.cash_accounts, etc, I got this sql for every account type:
where type = 'CreditCardAccount'
That is, all of the generated scope are pointed to the {where(type: 'CreditCardACcount')}
I don't know why.
here is the source file:
https://github.com/chylli/mypurse/blob/add_cash_demand_liability_credit_card/config/application.rb
https://github.com/chylli/mypurse/blob/add_cash_demand_liability_credit_card/app/models/account.rb
I think this is caused because a scope is given a Proc which is only executed when called, and so t will always be the last element of the loop.
A solution is to define methods instead of scopes (which work exactly the same) :
MyPurs::Application.config.available_account_types.each do |account_type|
define_singleton_method(account_type.underscore.pluralize.to_sym) do
where(type: "#{account_type}")
end
end
But since this does not declare a proc, this should work as expected.
Also the for .. in is rarely used in ruby, I personally prefer to use the more idiomatic .each (but of course you are free to use whatever you want, programmer happiness is key in ruby :) :)
Now as an aside, while meta-programming is really cool, you should really ask yourself if just listing the scopes is not way more readable. I understand: meta-programming is more DRY, but personally, in most cases where I did this, I reverted to the explicit definitions because of readability.
I am not sure why you have defined 'config.available_account_types', as this is business logic. this should belong to Account modal. so I would do something like this
class Account < ActiveRecord::Base
ACCOUNT_TYPES = %w(SystemAccount CashAccount DemandAccount LiabilityAccount CreditCardAccount)
ACCOUNT_TYPES.each do |acccount_type|
define_singleton_method(account_type.underscore.pluralize.to_sym) do
where(type: "#{account_type}")
end
end
end
In my Rails 4 app Project (model) has_many Videos (model). I have a named scope in the videos model:
scope :live, where( is_deleted: 0, sent_to_api: 1 )
In one of my project views, I do this (project is an instance of Project):
project.videos.live.size
What I expect to get is the number of projects in that specific project but instead I get the number of videos in any project. It's as if .live is not returning a subset from .videos but rather replacing it.
I see it explained here that chaining named scopes with one another should be combined with logical AND but when applied to an "association method" [<--not sure the proper terminology for .videos in this context] that doesn't seem to be happening.
What's the right way to do this?
I believe it should read like this in Rails 4:
scope :live, -> { where(is_deleted: 0, sent_to_api: 1) }
The rails 4 docs and all examples in it show you passing in a callable object to the scope to ensure it gets called each time. If it doesn't work like this try implementing it as a class method and see how that works out for you.
http://api.rubyonrails.org/classes/ActiveRecord/Scoping/Named/ClassMethods.html
I would just go for class methods and leave scopes behind. The syntax is much simpler because it's just like any other class method, including passing parameters to it.
Try:
def self.live
where( is_deleted: 0, sent_to_api: 1 )
end
And then:
project.videos.live.size
and see if it helps.
For more info, read here.
I'm trying to build factories for relatively complex models.
I have a Pressroom model, which belongs to Source, and Source has many Pressrooms. When creating the Source, if pressrooms is empty, an initial pressroom is created in an after_create filter.
The pressroom site must be unique per source.
class Source
has_many :pressrooms
after_create :create_initial_pressroom! # if pressrooms.empty?
...
end
class Pressroom
belongs_to :source
# source.pressrooms.map(&:site) should have unique elements
validate_on_create :check_unique_site
end
This leads to my problem: My Pressroom.make fails, because it builds a Source, which has no pressrooms, so the after_create callback creates one, and when the Pressroom.make tries to finish up, its site is not unique. I don't want to create two pressrooms when I run Pressroom.make
My attempt to solve this is to make the source association in the pressroom blueprint reference the pressroom. Sort of what Source.create :pressrooms => [Pressroom.new] would do.
Pressroom.blueprint do
source { Source.make :pressrooms => [self] }
site { source.site }
end
Unfortunatly, self is not yet a Pressroom. It's an instance of Machinist::Lathe, so I get an ActiveRecord::AssociationTypeMismatch exception.
I'm a bit of a newbie when it comes to factories and Machinist. I don't want to have to change the business logic, and I want to be able to cleanly make pressrooms with Pressroom.make without making two pressrooms in the process. If switching to factory-girl would help, I'm open to that.
I'd be grateful for any ideas on how to solve this.
Googling around, I found some hints on http://webcrisps.wordpress.com/2009/08/13/stubbing-before_create-callbacks-in-a-machinist-blueprint/ – to stub the after_create :create_initial_pressroom! callback on Source, in the Source blueprint – using Machinist 2 and Mocha here:
Pressroom.blueprint do
source { Source.make!(:without_initial_pressroom) }
site { object.source.site }
end
Source.blueprint do
site
end
Source.blueprint(:without_initial_pressroom) do
object.stubs(:create_initial_pressroom!).returns(true)
end
This way, Pressroom.make! works like it should, Source.make! works like it should, and... I guess I'm happy. But still a bit perplexed by the problems I ran into in the solution I tried above (both in machinist 1 and 2).
If anyone knows how to make this work with object, let me know. It'd be a lot cleaner, and besides, I generally don't like accepting my own answers here on stackoverflow.
Are you using Machinist 1 or 2? These suggestions for Machinist 2 and may or may not work in Machinist 1. I can't remember how you do this in Machinist 1 (and can't be bothered to google!).
To do it in the way you're suggesting, you need to use object:
Pressroom.blueprint do
source { Source.make :pressrooms => [object] }
site { source.site }
end
But a much nicer way to do it is to take advantage of the fact Machinst knows about the models associations and just let it do its thing:
Pressroom.blueprint do
source
site { source.site }
end
Assuming your associations are setup correctly, that should work. See the Blueprints wiki page for more.
I have a basic has_many :through relationship that is bi-directional:
calendars have many calendar_calendar_events
calendars have many events through calendar_calendar_events
events have many calendar_calendar_events
events have many calendars through calendar_calendar_events
I'm wanting to assign calendars to an event with the basic calendar_ids= function that has_many :through sets up, however, I want to override this function to add some extra magic. I've had a look through the rails source and can't find the code for this function. I'm wondering if someone could point me to it. I'll then override it for this class to add the stuff that I want :)
You can find the source code in the file lib/active_record/associations.rb at line 1295
def collection_accessor_methods(reflection, association_proxy_class, writer = true)
collection_reader_method(reflection, association_proxy_class)
if writer
define_method("#{reflection.name}=") do |new_value|
# Loads proxy class instance (defined in collection_reader_method) if not already loaded
association = send(reflection.name)
association.replace(new_value)
association
end
define_method("#{reflection.name.to_s.singularize}_ids=") do |new_value|
ids = (new_value || []).reject { |nid| nid.blank? }
send("#{reflection.name}=", reflection.class_name.constantize.find(ids))
end
end
end
You should definitely avoid to overwrite such this method to add magic stuff.
Rails is already "too much magic" sometimes. I would suggest to create a virtual attribute with all your custom logic for several reasons:
some other rails methods might rely on the default implementation
you rely on a specific API that might going to change in future ActiveRecord versions
After a bit of a hunt I found it:
http://apidock.com/rails/ActiveRecord/Associations/ClassMethods/collection_accessor_methods
It didn't look like what I thought it would look like, so that's why I probably missed it. I ended up overriding the calendars= method instead of the calendar_ids= method and everything works well.
In response to the answer above, I used alias_method_chain to override the default setter and add my feature. Works quite well, though I'm not sure why I have to send the method setter instead of just using it normally. It didn't seem to work though so this will do :)
def calendars_with_primary_calendar=(new_calendars)
new_calendars << calendar unless new_record?
send('calendars_without_primary_calendar=', new_calendars) # Not sure why we have to call it this way
end
alias_method_chain :calendars=, :primary_calendar