Skip to content

Latest commit

 

History

History
48 lines (37 loc) · 1.64 KB

2014-09-29.md

File metadata and controls

48 lines (37 loc) · 1.64 KB
Raw

AR Separating static data

excerpt from tenderlove blog post: http://tenderlovemaking.com/2014/02/19/adequaterecord-pro-like-activerecord.html

Its pretty interesting read about how sql generation changed overtime, and how caching sql generation works. Im copy pasting a part of blogpost here:

Separating Static Data

Let’s consider this statement:

  Post.find(params[:id])

In previous versions of Rails, when this code was executed, if you watched your log files, you would see something like this go by:

SELECT * FROM posts WHERE id = 10
SELECT * FROM posts WHERE id = 12
SELECT * FROM posts WHERE id = 22
SELECT * FROM posts WHERE id = 33

In later versions of Rails, you would see log messages that looked something like this:

SELECT * FROM posts WHERE id = ? [id, 10]
SELECT * FROM posts WHERE id = ? [id, 12]
SELECT * FROM posts WHERE id = ? [id, 22]
SELECT * FROM posts WHERE id = ? [id, 33]

This is because we started separating the dynamic parts of the SQL statement from the static parts of the SQL statement. In the first log file, the SQL statement changed on every call. In the second log file, you see the SQL statement never changes.

Now, the problem is that even though the SQL statement never changes, Active Record still performs all the translations we discussed above. In order to gain speed, what do we do when a known input always produces the same output? Cache the computation.

Keeping the static data separated from the dynamic data allows AdequateRecord to cache the static data computations. What's even more cool is that even databases that don’t support prepared statements will see an improvement.