Categories
open all | close allTags
スキンエンジン | ドキュメント | Migration | テスト | アクセス制御 | フォーム | Subversion | Flash | OpenID | CSRF | パソコン | 名称 | デュアル・コア | タグ | RESTful | モデル | Aptana | rake | 国際化 | 認証Search
解決：プラグインからDBのテーブルを作る方法
見つけました。というか独自にテーブルが必要そうなプラグインをインストールして，どうやっているかを見てみました。とりあえず以下のコードで動くことを確認。
class TestDB
def createtable
ActiveRecord::Schema.create_table('test') do |t|
t.column :str, :string
end
end
endこれをlibディレクトリにtest_db.rbとして保存し，コンソールを開いて a = TestDB.new と a.createtable を実行したらテーブルができました。実際にはテーブルの存在チェックなどが必要ですが，ともかくこれでプラグイン内でテーブルが作れることが分かりました。
ActiveRecord::Schemaのドキュメントを見ると
ActiveRecord::Schema.define do
create_table :authors do |t|
t.string :name, :null => false
end
add_index :authors, :name, :unique
create_table :posts do |t|
t.integer :author_id, :null => false
t.string :subject
t.text :body
t.boolean :private, :default => false
end
add_index :posts, :author_id
endといった書き方ができるようです。
プラグイン・オプションも含めてプラグイン内マイグレーション機能を入れたら結構使いやすいのではないかといったことを考えています。
「JustPosted」の実装
Nucleusで未来のポストのときに，公開されたところでpingを送るJustPostedが実装されましたが，あの実装方法はちょっとアレなところがあります。ポストされたら必ずイベントが発行されるので，「このアイテムでは送りたくないな」といった機能を入れようとすると，プラグインがテーブルを持ってアイテムごとに状態を保持しないといけないことになってしまいます。
そういったところを考えると，アイテムにipostedフィールドを持たせるよりも，未来のポストになっているアイテムについて，プラグインがpingの予約を保管できるようなテーブルをシステム側で持っている方がプラグイン開発の効率が良さそうです。
瑣末なところかもしれませんが，テーブルの設計に関係するので，開発者としては気になる部分です。