Problem populating a model with external data

rubyonrails-talk
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

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

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.

3. 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.

4. 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.

5. 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.

6. 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