Watch out for the scaffolding
One of the “neat” things about the whole Ruby on Rails doohicky is that it can build a lot of the basic drudge-code for you … automagically. Unfortunately, that sometimes bites you in the arse. I have hit just such a moment, apparently. Et voila:
[petrilli@bigbird aias]$ ruby script/generate scaffold EVENT_DATA
dependency model
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/eventdat_a.rb
create test/unit/eventdat_a_test.rb
create test/fixtures/eventdat_as.yml
exists app/controllers/
exists app/helpers/
create app/views/eventdat_as
exists test/functional/
create app/controllers/eventdat_as_controller.rb
create test/functional/eventdat_as_controller_test.rb
create app/helpers/eventdat_as_helper.rb
create app/views/layouts/eventdat_as.rhtml
overwrite public/stylesheets/scaffold.css? [Ynaq]
force public/stylesheets/scaffold.css
create app/views/eventdat_as/list.rhtml
create app/views/eventdat_as/show.rhtml
create app/views/eventdat_as/new.rhtml
create app/views/eventdat_as/edit.rhtml
error Before updating scaffolding from new DB schema,
try creating a table for your model (EVENTDATA)
There are a couple problems here that I see. First, the error at the end. The table exists, although it happens to be a MERGE table in MySQL, but that shouldn’t matter. I thought, from some links I found elsewhere, that perhaps it was my MySQL driver, but I downloaded the mysql gem, installed it, and ta’da it fails still. The table is there in all its glory, and remotely connecting via the configured user shows it to be there correctly as well.
Notice the naming of the scaffold doodads: eventdat_as. This is very curious. I played with some things I saw, such as setting ActiveRecord::Base.pluralize_table_names to false, but that didn’t seem to fix anything related to this problem. It did, however, fix some other issues I was running into with pluralization assumptions in Rails. Ick, assumptions are evil, but there they are. Never avoided.
Chatting with tufty on the #rubyonrails IRC channel, he observed that it happens all the time to him, but seems to be involved with table names in ALL CAPS. Hmm, curiouser and curiouser. More looking tomorrow, as it’s after midnight, and my brain is somewhat less than sharp.
This appears to be a known problem, and one that there is no intention of fixing. This seems painfully short-sighted since new apps are one domain of problems, but being able to glue together old apps is another. Not messing up so obviously is a big thing in that case.
This entry was posted at 12:15 am on 1 July 2005 and is filed under Ruby. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
What is frustrating, at this point, is that nobody seems to provide good “examples” of what you need to build if you don’t use the generator. Perhaps it’s just late, but I’ll look at it later and see if I can figure it out.
I tried most of the above as well, but nothing seems to solve the problem. I think the scaffolding becomes confused when the table name (in its singular form) is appended with ’s’ (‘sys_status’ in my case, ‘eventdat_as’ in your case, ...). Renaming the table (singular with an ’s’) and setting the ActiveRecord::Base.pluralize_table_names = false in environment.rb worked for me.
Ok well it seems that following the steps outlined here: http://weblog.rubyonrails.com/articles/2005/10/30/get-10-15-more-performance-with-mysql-rails
fixed this for me.
Both comments and pings are currently closed.
Hey,
that’s a known problem with the scaffold generator. But you can still use scaffolding with ‘strange’ table names.
Just generate a controller and put this into it’s definition.
scaffold :model_name
That will add all the actions and views it needs to, and you can still use all the set_table_name magic in your models too.
The scaffold generator is a little limited, and to be honest, I don’t use it.