Comments on: Ruby Code Audit Checklist http://www.pathf.com/blogs/2008/07/1008/ Running commentary about agile development, user experience design and Ajax. Fri, 09 Jan 2009 08:33:26 +0000 http://wordpress.org/?v=2.5.1 By: Pathfinder Development » Dealing With A Legacy http://www.pathf.com/blogs/2008/07/1008/#comment-3320 Pathfinder Development » Dealing With A Legacy Fri, 05 Sep 2008 19:03:00 +0000 http://www.pathf.com/blogs/?p=1008#comment-3320 [...] A couple of months ago, I wrote about auditing existing Rails applications en route to potentially taking them over. [...] [...] A couple of months ago, I wrote about auditing existing Rails applications en route to potentially taking them over. [...]

]]> By: Pathfinder Development » Resolved: Should schema.rb be included in your source control? http://www.pathf.com/blogs/2008/07/1008/#comment-2500 Pathfinder Development » Resolved: Should schema.rb be included in your source control? Fri, 18 Jul 2008 17:39:45 +0000 http://www.pathf.com/blogs/?p=1008#comment-2500 [...] a couple of weeks ago in the code audit post I wrote that I would consider it a big problem if the code base I was investigating couldn't run [...] [...] a couple of weeks ago in the code audit post I wrote that I would consider it a big problem if the code base I was investigating couldn’t run [...]

]]> By: Jon Wood http://www.pathf.com/blogs/2008/07/1008/#comment-2342 Jon Wood Thu, 10 Jul 2008 09:40:40 +0000 http://www.pathf.com/blogs/?p=1008#comment-2342 <blockquote>Failing a migration from scratch would be a big problem.</blockquote> It really shouldn't be - that's what the schema.rb is for. The "best practice" (I hate that phrase!) is to use db:schema:load when you first setup a new project, which is not only a lot quicker then running all the migrations, but is also less likely to explode later on because something changed. You also mentioned in your project tutorial that you don't keep schema.rb in version control. That's possibly one of the most important files you can have there, since it's used to bootstrap a new production server.

Failing a migration from scratch would be a big problem.

It really shouldn’t be - that’s what the schema.rb is for.

The “best practice” (I hate that phrase!) is to use db:schema:load when you first setup a new project, which is not only a lot quicker then running all the migrations, but is also less likely to explode later on because something changed.

You also mentioned in your project tutorial that you don’t keep schema.rb in version control. That’s possibly one of the most important files you can have there, since it’s used to bootstrap a new production server.

]]>