Problem populating a model with external data

Rails
1

I’m trying to populate a table with the names and attributes of files
in public\data\csv.

The ultimate target is a currently empty Sqlite3 database which yields
the following dump:
CREATE TABLE “csv_items” (“id” INTEGER PRIMARY KEY AUTOINCREMENT NOT
NULL, “filename” varchar(255), “created” date, “modified” date,
“imported” date,
“created_at” datetime, “updated_at” datetime);

Logger.info shows that I accessed the desired filenames, thanks to
this newsgroup.

I changed CsvItemsController#index as follows:
# @csv_items = CsvItem.find(:all)
@csv_items = get_csv_filenames_attributes

In def get_csv_filenames_attributes
# I populated a “values” array with the names of the files I
imported; then …
array = []
values.each { |filename|
item = CsvItem.new
item.filename = filename
item.created = Date.new (I’ll put in real values when I get this
problem solved.
item.modified = Date.new
item.imported = Date.new
array << item
}
array
end

That seems to work, except some of the .erb’s became unhappy. So I
assume there’s something wrong with the way I populated @csv_items.

I posted the following on http://www.pastie.org/325017:
csv_items_controller.rb
index.html.erb (the first .erb to complain)
http://localhost:3000/csv_items (which shows the symptoms)

TIA,
Richard

2

A couple of blemishes on my post. Obviously:
The pastie hyperlink should be http://www.pastie.org/325017
The other hyperlink doesn’t make any sense. It’s content is the third
item on the pastie page.

I apologize for seeing how things would get displayed on the
newsgroup. I doubt anybody will really be bothered by it.

Richard

On Nov 26, 8:45 pm, RichardOnRails

3

Hello Richard,

In your project directory run: “rake routes”. Get used to using this
command to check that RoR agrees with what you think are valid routes.

Also, looking at your controller.index it seems that you are handing
the item list created from the csv filenames in to the index view.
The view is looking for each item’s id which is nil - it doesn’t get
set until the item is saved in the database.

The line in index that you have commented out should be run to
generate @csv_items.

You need to figure out how you’re going to load the database before
you try to display it’s contents.

Rick

On Nov 26, 4:05 pm, RichardOnRails

4

Good Morning, Rick,

I just woke up and thought, “Hey, I didn’t give the items an id …”,
but then realized the field is auto-indexed by Sqlite3. Ah, but then
there are fields something like date_created, etc. Like Scarlett in
“Gone With The Wind”, I decided to think about that after I check my
newsgroup to see if someone generously posted a needed insight.

Thank you again for graciously sharing your hard-earned RoR insights
with newbies like me as well as others.

rake routes

Amazingly, I was just up to page 27 in “Practical REST on Rails 2
Projects”, which includes an inset entitled “Route Inspection: Rake
Routes”. I surely will be studying that.

For the moment, I think I understand the major error in my plan on
updating the database due to new or changed data in the “/public/data/
csv” directory. Here’s my new plan:

  1. I should include a “:before => :check_csv_status” in “/app/
    controllers/application.rb”.

  2. Then that “checker” can determine whether the “/public/data/csv”
    directory has changed. That can be done by:

  • check the timestamps;
  • validate saved checksums; or
  • compare against saved and hidden copies.

  1. Then if any difference is found, put up a flash notice that the
    system is “stale” and have a always-visible “update cvs table” link.

  2. Then “update cvs table” can use a portion of the techniques in “app/
    controllers/csv_items_controller.rb” to accomplish adding new items,
    updating existing ones and removing ones according to the current
    content of the “/public/data/csv” directory. And thus the database
    will be brought up to speed.

  3. For efficiency, perhaps a global, initially “false”,
    “cvs_table_up-to-date” switch should be set so that the check is only
    made at the beginning of a session. Users who tamper with the “/
    public/data/csv” directory mid-session do so at their peril.

  4. Maybe the last step of the update cvs table should be the command I
    heard so often in the military: “As you were!”, which translates to
    “resume the process you were involve in when you clicked the “update
    cvs table” link. I don’t know how to do that right now, but I’ll
    figure it out in due time.

Does this sound like a coherent design to you.

Again, Rick, thanks for your guidance.

Best wishes,
Richard