Comments on: Checking for Model Classes Before Using Them in Rails Migrations http://www.peterkrantz.com/2007/models-in-migrations-tip/ A blog about technology, visualization, music and unmanned vehicle experiments Sat, 06 Sep 2008 01:39:31 +0000 http://wordpress.org/?v=2.6.1 By: Aleksey Gureiev http://www.peterkrantz.com/2007/models-in-migrations-tip/#comment-2180 Aleksey Gureiev Thu, 24 Jan 2008 07:02:08 +0000 http://www.peterkrantz.com/2007/models-in-migrations-tip/#comment-2180 Interesting topic you raised there. As far as I know though, the creators of Rails strongly suggest not using migrations to configure an empty database for an application -- use the generated schema.rb instead. This avoids any problems with moving through migration steps with non-existent models and, what's more important, works times faster. Migrations are useful when there's an application running and you need to catch up with the development changes without losing any data. In this case you most probably won't face the problem with missing models. Thanks for the articles. The one with the Hpricot buffer size is a real healer. Interesting topic you raised there. As far as I know though, the creators of Rails strongly suggest not using migrations to configure an empty database for an application — use the generated schema.rb instead. This avoids any problems with moving through migration steps with non-existent models and, what’s more important, works times faster.

Migrations are useful when there’s an application running and you need to catch up with the development changes without losing any data. In this case you most probably won’t face the problem with missing models.

Thanks for the articles. The one with the Hpricot buffer size is a real healer.

]]> By: Pete http://www.peterkrantz.com/2007/models-in-migrations-tip/#comment-1963 Pete Thu, 07 Jun 2007 15:16:39 +0000 http://www.peterkrantz.com/2007/models-in-migrations-tip/#comment-1963 Akita: Migrations run in order but if you use model classes a migration may depend on a specific version of the code tree. When I wanted to set up a new development environment I got the latest source code. The latest source code didn't include the County model (it had been scrapped earlier). The tables were created properly in migration 009, County inserts in 010 and the data and table were removed in migration 015. Akita: Migrations run in order but if you use model classes a migration may depend on a specific version of the code tree. When I wanted to set up a new development environment I got the latest source code. The latest source code didn’t include the County model (it had been scrapped earlier). The tables were created properly in migration 009, County inserts in 010 and the data and table were removed in migration 015.

]]> By: AkitaOnRails http://www.peterkrantz.com/2007/models-in-migrations-tip/#comment-1962 AkitaOnRails Thu, 07 Jun 2007 13:50:27 +0000 http://www.peterkrantz.com/2007/models-in-migrations-tip/#comment-1962 I understand this but wasn't Migrations supposed to run in order? I mean, even if the database is empty it means that in some point it will reach the creation of the Countries tables (say, in migration number 010) and this data loading would take place necessarily after that (say, in migration number 021). This checking would necessary if you want to run the migrations out of order, but this defies the whole purpose of the schema_info versioning control, doesn't it? I understand this but wasn’t Migrations supposed to run in order? I mean, even if the database is empty it means that in some point it will reach the creation of the Countries tables (say, in migration number 010) and this data loading would take place necessarily after that (say, in migration number 021). This checking would necessary if you want to run the migrations out of order, but this defies the whole purpose of the schema_info versioning control, doesn’t it?

]]>