このあたりの記事が非常に参考になりました。
優しいRailsの育て方:Migration
MigrationのRDoc
要するに、
1.2の時代はgenerate scaffoldはDBスキーマの情報を動的に取得して各種ソースを生成していたが、これは、DBを先に修正した上でgenerate scaffoldするという、DB中心の開発を意味する。
2.0のようなscaffoldの扱いでは、Modelを修正してそこから各種ソース+Migrationファイルを生成し、生成されたMigrationファイルを(rakeで)実行することでDBをアップデートするという、Model中心の開発になると思われる。これは、元々Railsから派生したフレームワークである、Groovyの思想に近くなっている。
ということで、次は最初からbookmarkアプリを作成し、Modelに新たなプロパティを追加した後にMigrationからDBに反映させるという手順を試してみることにする。
関連リンク:
Rails2.0リリース
Rails2.0のscaffoldは前とだいぶ違うらしい
Rails2.0でブックマークアプリ
Rails2.0の変更点
Action Pack: Resources
Action Pack: Multiview
Action Pack: Record identification
優しいRailsの育て方:Migration
MigrationのRDoc
要するに、
- DBスキーマをRubyで記述することで物理DBの詳細に煩わされることなくアプリとDBを管理するメカニズム
- Rubyで書かれたスキーマファイル をバージョン管理(それぞれのスキーマファイルには、バージョンを進める/戻すための操作を定義)することもできる
1.2の時代はgenerate scaffoldはDBスキーマの情報を動的に取得して各種ソースを生成していたが、これは、DBを先に修正した上でgenerate scaffoldするという、DB中心の開発を意味する。
2.0のようなscaffoldの扱いでは、Modelを修正してそこから各種ソース+Migrationファイルを生成し、生成されたMigrationファイルを(rakeで)実行することでDBをアップデートするという、Model中心の開発になると思われる。これは、元々Railsから派生したフレームワークである、Groovyの思想に近くなっている。
ということで、次は最初からbookmarkアプリを作成し、Modelに新たなプロパティを追加した後にMigrationからDBに反映させるという手順を試してみることにする。
関連リンク:
Rails2.0リリース
Rails2.0のscaffoldは前とだいぶ違うらしい
Rails2.0でブックマークアプリ
Rails2.0の変更点
Action Pack: Resources
Action Pack: Multiview
Action Pack: Record identification
コメント