Danny O Cuiv

Hi,

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:
actual.save
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 = StatusReport.new(:status_date => 10.days.ago.to_date)
=> #
>> 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,

Danny.

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.

Danny.

Thanks Noel for your answer to my previous question. I’ve got another. On page 77 of the print edition (or page 83 of the PDF), you say:

This means you can’t use arbitrary methods of the model as attributes in the fixture the way you can in a create( ) call. Fixture attributes have to be either actual database columns or ActiveRecord associations explicitly defined in the model.

This implies to me that things like virtual attributes are allowed in a call to create, whereas fixtures are restricted to actual database columns (and associations). I was curious and looked this up in the API. create() just calls new() before saving and in the documentation for the new() method, it states:

In both instances, valid attribute keys are determined by the column names of the associated table – hence you can’t have attributes that aren’t part of the table columns.

This seems to me to be at odds with you wrote above. Can you clarify?

Thanks,

Danny.

From page 16 of the print edition:

For its part, Rails smooths out the difference between minitest and Test::Unit 1.3 and adds its own features on top of both. For our purposes, we don’t need to worry about the difference, and to minimize confusion (too late?), I’ll continue to refer to that library as Test::Unit. Since I’m boldly assuming you are writing a Rails application, I’m not going to sweat the difference between what’s in Rails and what’s in Test::Unit. Test::Unit 2.0 doesn’t seem to have much of a constituency at the moment, so I’m going to ignore it.

Danny

I’m going to bump this one if that’s OK. (It’s been almost two weeks and 130 views.)

Anyone got any idea what was being referred to here?

Thanks,

Danny.

Hi James,

My guess from the above is that you have downloaded the code from the PragProg site and used that in your work-through. However, this code is for the completed example. What you needed to have done is to get a starting setup as explained in Appendix A: Sample Application Setup. I say this because your first two errors above are undefined method errors for a method called users on a Project instance. This method is being called on line 5 of your show view for projects. When I was working through the example, there was no users association in the Project model at that stage and the first few lines of the show view were like this:

<p id="notice"><%= notice %></p>

<p>
  <b>Name:</b>
  <%= @project.name %>
</p>

However, in the version from the code download, there is indeed a call to project.users on line 5 of the show view:

The users association isn’t added until the top of page 243, much further on from where you are now. Oddly enough, this association is actually missing from the code download version. It should really be there.

Regards,

Danny.

status_date is an ActiveRecord attribute, which means that the accessors are generated, specifically a setter (status_date=) and a setter (status_date). When these are invoked from outside the class, there is no ambiguity

object.status_date = Date.today
and
foo = object.status_date

When you want to invoke them inside the class, the getter can be called unqualified, but you need to qualify the setter (with self), because of an ambiguity in the grammar. Specifically

status_date = Date.today

would look to the interpreter like an assignment to a local variable. Obviously you can qualify the getter too. It’s just that it’s not necessary.

Danny.