small medium large xlarge

01 Apr 2011, 16:18
Danny O Cuiv (7 posts)


I’ve been reading the book and enjoying the approach, but am stumped by a passage on page 48. Can anyone who has read the book enlighten me? The passage is:

“In this particular case, the controller creates a new instance from the database and saves that instance, without touching the actual variable created for the test. As a result, the database version has typecast the status_date to a Date when saving, but the live version in memory hasn’t gotten that change.”

So, my difficulties are:

(i) The controller creates a new instance from a hash, not from the database. (I can’t even think what creating a new instance from the database could mean.)

(ii) I’m not sure what is meant by saving the instance without touching the variable. The call is: Does this constitute not “touching” the variable?

(iii) Most puzzling of all is the bit about the database version having typecast the status_date to a Date when saving. As far as I can see, status_date was a Date right from the time the value appeared in the hash. Playing around on the console gives:

actual = => 10.days.ago.to_date) => #<StatusReport id: nil, project_id: nil, user_id: nil, yesterday: nil, today: nil, status_date: “2011-03-10”, created_at: nil, updated_at: nil> actual.status_date.class => Date

So that status_date was always a Date. What’s meant by it being “typecast” to a Date?

Thanks in advance,


05 Apr 2011, 13:33
Danny O Cuiv (7 posts)

I’m going to bump this one, if that’s OK. It’s had a good number of eyeballs at this stage, but nobody’s replied. Which either means that it’s a really basic question or it’s a really badly phrased passage.

Let me simplify my question. An object is created with attribute called status_date that is of type Date. It’s saved to the database. After retrieval, you will still get a Date object if you read the attribute. In what sense is there any kind of “typecast” happening here?

If anyone has any insights, I’d be very grateful.


06 Apr 2011, 22:06
Noel Rappin (48 posts)

It’s a badly phrased passage.

Well, it’s a passage that seems to have been moved out of it’s original context, and doesn’t make sense where it is.

The text in question really applies largely to controller testing, as the following paragraph in the book suggests. I suspect this paragraph that is confusing you was originally placed near a controller test, but got moved, and it’s meaning got garbled.

The problem that you try to solve with reload is this:

  1. You create an instance of an object in a test, and save it to the database, call this instance “foo”

  2. You then make a call into the application, where that object is read from the database into a new Ruby object, call it “bar”. This is most common when you create an object, and then call, say, the show method of a controller via the ID, the controller reads the object from the database and creates a new object in memory backed by the same database row. (That’s what I mean by “creates a new instance from the database”, which, again, doesn’t actually apply to the example as I said it does.)

  3. You make changes to instance “bar” in the code, and those changes get saved to the database

  4. Now in the test, you still have a reference to “foo”, but “foo” does not have the changes made to “bar” and saved to the database, because they are two different objects. You call “reload” to allow the “foo” instance to have changes made to “bar”.

Now, about the typecast issue. I believe that what I was trying to guard against is that when you create the instance from the ActiveRecord code, the status_state is a Date object, but when you read one from the database, it is a DateTime object, so you need to change one into the other in order to do a comparison. Your IRB snippet is correct, but if you had done a create on the object, and then read it back out of the database, the status_date.class would be a DateTime. I can’t completely recreate this right now, but I’ll give it a try later and report back.

Sorry about the confusion – I think this one should have been caught.


06 Apr 2011, 22:27
Noel Rappin (48 posts)

Following up. Since status_date is a Date in the database, the type issue is not a problem in this case. It would be if you were using created_at.

So this text seems to be totally out of sync with the example it is near.

I’m sorry about that. I’ll put an errata in so that it will be clarified in the text.

Thanks for letting me know about this issue.