For those of you who ever have to do Rails work with an older database that was not created according to RoR naming specs and to which other things have been coded such that you can’t just rename everything, here’s something I found out the hard way. I created my model and used set_table_name to point to the correct table in the DB. I could do a :scaffold in the controller and everything worked fine. However, if I tried to generate the scaffolding so I could modify it, I’d get the dreaded “Before updating scaffolding from new DB schema, try creating a table for your model” error. I was befuddled why a scaffolding that was working would give such an error on generate.
After much googling, I found out that the scaffold generator ignores your existing model, and only has the capacity to create from the tablename it expects based on your model and controller names. To get around this, I renamed the table to what Rails expected, generated the scaffold, named the table back to the original and then used the set_table_name to point to the original table name. I think it’s kind of a pain this way, but the workaround is to temporarily make the name what RoR wants just long enough for the generation, and then set it back. It beats copying the scaffolding from a different class and changing everything by hand, which is what I did the last time this came up.
Thanks, I’ll try to remember this!
I’m making a Web 3.4.7 app 😉 in Ruby, and while I’m not using existing databases at the moment, at some point I might.
Good to know. It seems like there are a ton of things like this in Ruby on Rails. I guess the more work a framework does for you (like scaffold, etc), the harder it is to figure out when you want to do something a little different.
After playing around with RonR for a while, I also decided to do a project at work using it. Its basically a web front end to simulation test software. I was fine running the command line test software by hand, but my manager wanted an easier way to run it than reading the long-ass man page 🙂 I have spent may couple-hour sessions getting “just that one simple thing” to work.
Good luck to both of you!
This has been pretty much my experience too. Initially you make huge gains, scaffolding and all the auto-magically generated code is great, then you have this huge wall to overcome in learning the framework and (if you don’t already know it) ruby. Once you understand the assumptions that rails is making, I imagine productivity goes back up to the initial curve.
Deployment seems to be a big headache too, but getting better.
Hedley,
How is deployment of a Rails app any different than deploying PHP, or a Perl-based web app? Specifically, how are you/were you having trouble deploying Rails apps? I’m not saying you’re wrong. Maybe I’m just not seeing the same problems you are? Tell us your issues, and maybe we can help?
I do agree about the learning curve and productivity. Once you extend beyond the reach of the Rails handholding, you have to dig deep within the framework and documentation (both informal and formal) for the answers. That slows you down a lot.
Hopefully this will be addressed by the upcoming Rails books. I especially have high regards for the just announced O’Reilly Ruby Cookbook (already available as an electronic Rough Cut, which I’m digging a lot as a publishing model for the early adopters). Hopefully a Rails Hacks and a Rails Developer’s Notebook are coming soon.
I became super productive over the last week. Things are really clicking now. =)
I have run into a few issues with deployment. They are not really worth listing, as they are all challenges that can be solved, just not anticipated in project time lines. One issue we still haven’t gotten a chance to solve is how certain deployments will have some serious trouble with file upload processing, where the file object will exist but always return null data when trying to pass to any of my image uploading code. Too busy right now to dig too deep into it, we just used a different box/os to host our product.
Picked up O’Reilly’s ‘Ruby in a Nutshell’ this weekend, got sick of all the online digging around. There was one copy in all of downtown Seattle, sheesh. I won’t let this one leave my side, love it.
Maybe you should try migration in order to rename your tables, could save you alot of work
http://api.rubyonrails.com/classes/ActiveRecord/Migration.html
Matt, as I explained in the very first line of this post, there was sufficient legacy stuff already written to the current database such that just renaming the tables and columns was not a viable option in this particular situation. The problem wasn’t that I lacked the wherewithall to rename the tables, it was that I would break everything else if I conformed it to Rails naming conventions. That’s the hidden cost of adding Rails to existing systems where the standard RoR option of “hey, let’s just rename it all” isn’t viable. Either you take the hit on the legacy side or the RoR side, but there is definitely a hit.
I can’t believe it works!
Good Man! Thanks for sharing!
Thanks for the info. It didn’t solve my problem (yet), but I’ll get it work eventually! I’m in the same boat – Ruby seems great for that new development work, but to write new stuff for a legacy system seems to be a bit of a challenge.
if you have the permission to rename the table, you might want to create a view on the original table with the new name. something like an alias. of course, most people who don’t have permission to rename the table don’t have permission to create views.
Thanks for workaround, now lets see how long it takes for a solution. I’m finding 20% of rails conventions are so counter-productive to get around they really ruin the gains of the framework, this sounds like yet another example.
Rails isn’t that bad if the legacy system had a consistent naming scheme in their databases. For instance, suppose that the primary key is ‘tablename_id’ rather than ‘id’. Add this line to the appropriate config/environment.rb:
ActiveRecord::Base.primary_key_prefix_type = :table_name_with_underscore
Suppose that the primary key of every table is ‘foo’ instead of ‘id’:
ActiveRecord::Base.set_primary_key = “foo”
Convention is great, but when it doesn’t do what you need it too, there is usually a simple configuration change to solve it.
I found a work-around through Google that advise adding “identified by” to the grant stmts, notwithstanding that password is provided in the YAML. That worked for me, a Ruby & Rails newbie.
But when I made a DB change and tried recreating the scaffolding, the dreaded “try creating a table” message reappeared.
I’d like to try your fix, but I don’t know where to stick it. I’ll email you in hopes of getting a fast answer. Thanks for posting your hints.
I solved my problem. I was mixing up names in my app with names from the sample app in Agile Web Dev with Rails. However, I do think that adding ‘identified by’ clause in the grant stmts is critical, at least on my WinXP-Pro/SP2 box with MySQL/Community 5.0.
Good luck, y’all!
In Oracle I got the scaffold to work by creating a Synonym for the table with the expected plural form of table name.
makes complete sense now. this same problem left if befuddled .
thanks for blogging your findings. tis made my life a lot simpler!
The way to solve these issues is to add an inflection to the environment.rb file. In my case:
Inflector.inflections do |inflect|
inflect.irregular ‘journey’, ‘journies’
end
You should take a look at http://activescaffold.com/ which allows you much more flexibility with the scaffolding. I’m not entirely sure if it helps your particular problem though. Also, http://www.streamlinedframework.org/ is useful for view type scaffolding.
I just wrote some intro to setting up ActiveScaffold and overriding defaults here:
http://blog.akilles.org/2008/04/17/ruby-on-rails-experimenting-with-activescaffold/