Category Archives: Ruby on Rails

alias_method_chain and ActiveRecord

Posted on by
Reply

I just encountered an interesting scenario that I felt deserved some discussion:

I needed to make a middleware function for getting an ActiveRecord association, and for whatever reason it occurred to me that alias_method_chain was going to be the right way to do it.  While this instinct turned out to be correct, it didn’t occur to me at the time the fact that ActiveRecord sometimes does tricky things involving method_missing and not actually defining its method names.  So when I then had to make a middleware function for getting/setting an ActiveRecord column, I turned to alias_method_chain once more.  Well, when I tried doing that, I received “NameError: undefined method” for the name of the column that I was trying to alias.  What gives?  Why did one of these work and not the other one?

As I mentioned, ActiveRecord overrides the method_missing method to “define” some of its method names during runtime, but although column names are in this list, associations are not.  Therefore, when you define “belongs_to” or “has_many” in your model, it is creating multiple methods at build time to assist you, named with the specific name you passed it.  Column names, however, are not technically defined in the model or anywhere else in code, but by simply what the database returns when asked for these records.  So when you call the name of a column as a method on an ActiveRecord object, it first recognizes that no such method exists, and it then redirects the request to see if any column can be fetched (or has been fetched) from the database with this name.  (Note that this means you can finagle Rails into recognizing anything you select as a “column”, such as aggregations or other calculated values.)  Alias_method and Alias_method_chain require that the method you are trying to alias exists in the first place, so this simply will not work for this case.

If you really think about it, however… Why try to alias something that doesn’t exist in the first place?  Obviously, you can simply write the method yourself and bypass all of the method_missing magic, as long as you know what to reproduce.  The below is how you would reproduce the accessors for the attribute “name” (with no actual changes functionally):

def name
  read_attribute(:name)
end 

def name=(value)
  write_attribute(:name, value)
end

From there, it should be easy to see how to make the changes you want.

-CT

Easy Alternative to accepts_nested_attributes_for a has_many :through Relationship

Posted on by
Reply

I just found this out myself; I have no idea why this was kept secret from me for so long.  If you need an interface for linking multiple pre-existing model_ones to each of your model_twos, your first thought might be accepts_nested_attributes_for.  While that is a great and versatile tool, it is definitely not easy for every situation, of which I think this is one.  You would probably get stuck trying to figure out the best way to remove old links, recognize existing ones, and add new ones, all in as simple an interface as possible for the user.  For instance, wouldn’t this multi-select box be nice?

That was what I wanted.  What I found out (again?) was that you could do exactly that by writing simply:

<%= f.select :platform_ids, Platform.all.map{|p| [p.name, p.id]}, {}, :multiple => true %>

(Assuming that Game has_many :platforms, :through => :platform_relationships. Remember to put :platform_ids in your attr_accessible!)

So there you are.  Rails really is magic.  It seems that any has_many association recognizes an array of ids as a valid way to list and alter its child relationships in bulk, though the benefit for :through associations is much more meaningful.  The syntax is the collection’s name in singular + “_ids”, and the documentation claims the following:

collection_singular_ids=ids
Replace the collection with the objects identified by the primary keys in ids. This method loads the models and calls collection=.

A few notes:

  • Any children orphaned by this operation which are defined as :dependent => :destroy will be destroyed!  This is probably helpful clean-up, but definitely be aware of it.
  • For a :through association, the join model will be deleted, not destroyed (no destroy callbacks), and this appears to be independent of :dependent => :destroy.  This may not have adverse effects in most situations, and in fact is probably a good thing as the relationship model is automatically groomed for you.
  • If any of the child assignments doesn’t pass validation, the whole operation will fail.
  • The assignment operation cannot go through multiple join models, though you can get the current array of ids.  This makes sense in the end, because the second or third join models are probably not simple join models for which we have all the information necessary to create from scratch.

Enjoy!
-Comatose

Reconsidering Inherited Resources

Posted on by
Reply

When I had first started programming in Rails, someone recommended the gem Inherited Resources to me as a matter of course, implying that to go without it was to reinvent the wheel.  It definitely made many things easier for us, and it’s very well-made; it was already built to handle almost anything we threw at it.  Initialization values passed to the “new” action?  Got it.  Complicated parentage defined in the path?  Doable.

Now that I’ve started a new project, however, I’ve realized that I don’t really want to use it anymore.  Too many times I ran into situations where I had to figure out how to build my controllers around the Inherited Resources functionality, such as when I had to introduce extra variables that depended on variables already built by IR behind the scenes, or when the variables defined in the path to the action were greatly varying.  It was also fairly difficult to debug problems when the controllers were so obfuscated by outside function calls and the solutions to them had to be removed by so many degrees.  I realized that in the end it may have been faster (to program and to run) to just build it all myself, so that any modifications were easy to insert at exactly the appropriate place and any problems were easy to find and address.

It’s nothing against Inherited Resources; as I said, it is very well-made.  I just think that it’s not really for everyone.  My teacher may have been exaggerating a little bit.  I suppose we’ll see how I feel after reinventing the wheel a few times.

Dynamic Squeel Queries

Posted on by
1

Well, as the inaugural post to my blog, I figured I’d write about something that I had some trouble finding when I went looking for it some time back:  Dynamically building ActiveRecord queries in Ruby on Rails using the Squeel gem.

If you’re like me, you may have thoroughly enjoyed the vanilla ActiveRecord methods for the simplicity of the arguments they accept.  If you wanted to, you could build a hash using completely arbitrary means and then throw that hash over to an ActiveRecord “where” method and watch the magic happen.  Ernie Miller‘s brilliant MetaWhere gem (Squeel’s predecessor) built on that functionality by extending the very basic workings of symbols, which maintained for us the ability to pass such elegantly arbitrary arguments, only with greatly enhanced query building capabilities.  It is amazing, and anyone using Rails ~>3.0 should look into it.

However, you may have upgraded your app at some point to Rails 3.1+ to take advantage of all the new features, only to find out that MetaWhere is not supported in this version and you must switch to Squeel instead.  It will quickly become apparent to you that the way Squeel functions, using its domain-specific language (DSL) to contextualize all the SQL query building, does not allow for building your query through arbitrary means prior to using it in Squeel’s DSL context.  It must all be done inside of Squeel blocks passed to ActiveRecord methods.  That’s not to say it isn’t a great gem that does amazing things—it certainly is.  It just can’t be used the way I wanted to use it.  Or so I started to think…

Actually, you can simulate Squeel’s DSL in any context by using Squeel’s classes directly.  For instance, you can do things like:

# Returns a Squeel DSL object similar to:
# name.matches("%#{my{in_name}}%")
def query_for_name_matches(in_name)
  name_stub = Squeel::Nodes::Stub.new(:name)
  Squeel::Nodes::Predicate.new(name_stub, :matches, "%#{in_name}%")
end

You can then use it like this:

q = "Bob"
User.where(query_for_name_matches(q)) # Note: passed in parens ()

That’s pretty cool, but how far can we take this?  How do I use keypaths like posts.author.name?

# Note how these lines reference relative paths completely out of
# context. The context and meaning of these statements are
# evaluated at the time of use and no earlier, which is perfect for
# our purposes.
def query_for_authored_by(in_name)
  posts_join = Squeel::Nodes::Join(:posts)
  author_join = Squeel::Nodes::Join(:author)
  author_kp = Squeel::Nodes::Keypath(posts_join, author_join)
  name_kp = Squeel::Nodes::Keypath(author_kp, :name)
  Squeel::Nodes::Predicate(name_kp, :eq, in_name)
end

What about SQL functions, which Squeel supports?

lowername = Squeel::Nodes::Function.new(:lower, [name_kp])
# Note that it uses an array as the second argument

What about something crazy with an arbitrary number of ‘or’ statements and an outer join, maybe in a hash format?

def query_for_authors_named(*args)
  name_stub = Squeel::Nodes::Stub.new(:name)
  my_pred = args.inject(nil) do |running_pred, name|
    this_pred = Squeel::Nodes::Predicate.new(name_stub, :matches, "%#{name}%")
   #this_pred = query_for_name_matches(name)  # Remember?
    if running_pred
      running_pred | this_pred
    else
      this_pred
    end
  end

  {Squeel::Nodes::Join.new(:authors, Arel::OuterJoin) => my_pred}
end

> Post.where(query_for_authors_named("Bob", "Robert", "Tony"))

So you can see that all the power of Squeel is still there, as long as you know where to look.  It may be possible to do most of your queries on the spot in the Squeel DSL, but there are certainly times when it’s more convenient to piece things together externally.  I hope this helps someone!