Scaffold leads to OK database, but model empty

Hi,

I ran:
ruby script/generate scaffold Csv filename:string created:date
modified:date imported:date
rake db:migrate
sqlite3 db\development.sqlite3
.dump csvs (database columns displayed as expected)
type app\models\csv.rb (which displayed only:
class Csv < ActiveRecord::Base
end
with no field names)

I’m inclined to just populate the latter with:
@filename, @created, @modified, @imported

Is this the way to go, or is there some “Ruby Way”?

I’m running:
ruby 1.8.6
Rails 2.2.1

Thanks in Advance,
Richard

ActiveRecord automatically discovers the fields in your model’s table
and creates accessor methods for you at runtime, so the model shown is
all you need.

–Jeremy

On Mon, Dec 15, 2008 at 10:03 AM, RichardOnRails
[email protected] wrote:

class Csv < ActiveRecord::Base
Rails 2.2.1

Thanks in Advance,
Richard


http://jeremymcanally.com/
http://entp.com/

My books:

http://humblelittlerubybook.com/ (FREE!)

On Mon, Dec 15, 2008 at 8:12 AM, Jeremy McAnally
[email protected] wrote:

ActiveRecord automatically discovers the fields in your model’s table
and creates accessor methods for you at runtime, so the model shown is
all you need.

Exactly, and

ruby script/generate scaffold Csv filename:string created:date
modified:date imported:date

…probably worth mentioning that you can easily confirm something
like this by opening your Rails console and entering e.g.
@csv = Csv.new
and viewing the output.

FWIW,

Hassan S. ------------------------ [email protected]

Hi Hassan,

… opening your Rails console and …

Excellent addition. It’s so much better to have proof than relying on
faith.! Just to prove your effort wasn’t wasted on me:

K:_Projects\Ruby_Rails_Apps\PayrollSysAnew>ruby script/console
Loading development environment (Rails 2.2.0)

@csv = Csv.new
=> #<Csv id: nil, filename: nil, created: nil, modified: nil,
imported: nil, created_at: nil, updated_at: nil>

Many thanks,
Richard

On Dec 15, 11:21 am, “Hassan S.” [email protected]

Hi Jeremy,

… so the model shown is all you need.

Thanks. I was hoping I’d discover something of “The Rails Way”.

Best wishes
Richard

On Dec 15, 11:12 am, “Jeremy McAnally” [email protected]

@csv = Csv.new
=> #<Csv id: nil, filename: nil, created: nil, modified: nil,
imported: nil, created_at: nil, updated_at: nil>
One other thing that might be noteworthy…

Notice how your “created” and “modified” attributes are redundant with
“created_at” and “modified_at.” You might want to consider using the
ones provided by Rails by default. This way you have no additional work
in updating these standard fields. Rails with take care of them for you.

Then you also have the “imported” attribute. Since this is also a date
field you might want to follow the Rails convention for naming date and
time fields by appending “_at” or “_on” so you could have “imported_on”
if you want a date only or “imported_at” if you want to also record the
time along with the date.

Also note that the default attributes added by “t.timestamps” in your
migration will use date and time, but you can always format your view to
show date only if you want. And, of course, you will need to update the
value of “imported_at” yourself since it not something Rails can do
automatically.

Hi Robert,

Thanks for looking carefully at my approach. I value your warning
that my names for the date fields I defined may be redundant.

Notice how your “created” and “modified” attributes are redundant with “created_at” and “modified_at.”

Every Csv instance is intended to record attributes of a file
discovered in public\data\csv directory. So the “created” field will
record the date the file in question was created. The created_at
attribute will record the data the instance (and thus the
corresponding database record) was created. So I believe they are two
different date values.

As far as the date format is concerned, I plan to use (for example)
File.new(filename).ctime.strftime(pattern) in view.

Does that make sense, or do you think I am confused in this
perception? Please let me know.

Best wishes,
Richard

On Dec 15, 12:30 pm, Robert W. [email protected]