I'm a PHP developer learning the awesomness of Ruby on Rails, I'm loving ActiveRecord and i noticed something really interesting, Which is how ActiveRecord methods detect the end of method chain to execute the query.
@person = Person.where(name: 'Jason').where(age: 26)
# In my humble imagination I'd think that each where() executes a database query
# But in reality, it doesn't until the last method in the chain
How does this sorcery work?
ActiveRecord is an ORM. It's a layer of Ruby code that runs between your database and your logic code. When you need to make changes to the database, you'll write Ruby code, and then run "migrations" which makes the actual changes to the database.
where returns an ActiveRecord::Relation (not an array, even though it behaves much like one), which is a collection of model objects. If nothing matches the conditions, it simply returns an empty relation. find (and its related dynamic find_by_columnname methods) returns a single model object.
Active Record is the M in MVC - the model - which is the layer of the system responsible for representing business data and logic. Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.
ActiveRecord::Base indicates that the ActiveRecord class or module has a static inner class called Base that you're extending.
The where
method returns an ActiveRecord::Relation
object, and by itself this object does not issue a database query. It's where you use this object that matters.
In the console, you're probably doing this:
@person = Person.where(name: "Jason")
And then blammo it issues a database query and returns what appears to be an array of everyone named Jason. Yay, Active Record!
But then you do something like this:
@person = Person.where(name: "Jason").where(age: 26)
And then that issues another query, but this one's for people who are called Jason who are 26. But it's only issuing one query, so where'd the other query go?
As others have suggested, this is happening because the where
method returns a proxy object. It doesn't actually perform a query and return a dataset unless it's asked to do that.
When you run anything in the console, it's going to output the inspected version of the outcome of whatever it is you ran. If you put 1
in the console and hit enter, you'll get 1
back because 1.inspect
is 1
. Magic! Same goes for "1"
. A variety of other objects don't have an inspect
method defined and so Ruby falls back to the one on Object
which returns something ghastly like <Object#23adbf42560>
.
Every single ActiveRecord::Relation
object has the inspect
method defined on it so that it causes a query. When you write the query in your console, IRB will call inspect
on the return value from that query and output something almost human readable, like the Array that you'd see.
If you were just issuing this in a standard Ruby script, then no query would be executed until the object was inspected (via inspect
) or was iterated through using each
, or had the to_a
method called on it.
Up until one of those three things happen, you can chain as many where
statements on it as you will like and then when you do call inspect
, to_a
or each
on it, then it will finally execute that query.
There are a number of methods that are known as "kickers" that actually fire off the query to the database. Prior to that, they just create AST nodes, which once kicked, will generate the actual SQL (or language being compiled to) and run the query.
See this blog post for a deeper explanation of how this is done.
You can read the code, but one concept here is the proxy pattern.
Probably @person is not the real object but a proxy to this object and when you need some attribute there the active record finally execute the query. Hibernate has the same concept.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With