Re: migrations不止可以更性感，还可以更感性，甚至更个性

[quote="rainchen"]
更性感的migration:

class User < ActiveRecord::Base  
  fields do  
    name :string, :null => false  
    email :string  
    about :text, :default => "No description available"  
  end  
end  

[/quote]

我还看到这样做的一个好处，更有利于Aspect Programming。

比如，Model假删除：现在Rails里的Model.destroy就是从数据库里彻底删除，我想把系统里的几个模型做成假的删除。就是把is_active字段设为false，find也找不到它。

要做到find找不到假删除的记录，只要hack一下ActiveRecord::Base就行了，但是is_active字段还是要一个个数据表里去加的。

如果把数据库字段也定义在Model里，就可以在一个插件里一揽子解决这个问题。

做一个插件，先添加一个is_active字段，default设为true，然后hack一下find，还要hack一下destroy。起个名字，比如acts_as_fake_delete。然后在需要的Model里call一下就都搞定了。

DRY的好处之外，是代码有意义。

实际项目的数据表中有不少功能性字段，比如Rails考虑到的created_at, updated_at,is_locked，再比如Rails没考虑的is_active,created_by, updated_by等等，都可以用插件抽象出来。

期待这个变化。

----
论坛中楼主回帖误解了我的意思，再多解释一下：

这样的例子在企业级应用里很常见，大量的数据表要有created_by（user_id），is_active，created_at这样的字段。

再举一个例子，每次用到created_by的话，都要先写migration，再在model里定义belongs_to :created_by_user, :class_name => 'User', :foreign_key => :created_by；还要before_save的时候设置self.created_by = current_user.id；以及controller/view上CRUD的一整套东西。现在因为必须用migration定义field，这个 “repeat yourself”的逻辑就不能彻底抽出来，做到增减随意。
----

更多讨论：http://www.iteye.com/post/387093