トップ  > メモ一覧  > カテゴリ「コマンド」の絞り込み結果 : 8件

8件中 1 〜 8 表示  1 

No.3072 権限を補正するコマンド

権限を補正するコマンド

【違い】
  • ./symfony project:permission : web/cache 以下は非対応
  • ./symfony openpne:permission : web/cache 以下も対応
更新:2010/10/04 12:47 カテゴリ: OpenPNE3  > コマンド ▲トップ

No.2958 「--no-update-plugin」とは

./symfony openpne:migrate --target=opCommunityTopicPlugin --no-update-plugin

「--no-update-plugin」とは
migrate 時にプラグインチャンネルサーバを見ないオプション→実行速度高!

更新:2010/08/26 16:21 カテゴリ: OpenPNE3  > コマンド ▲トップ

No.2726 ==■OpenPNE3のルーティングルールの確認

== ■OpenPNE3のルーティングルールの確認

■PC版の確認
./symfony app:routes pc_frontend

■Mobile版の確認
./symfony app:routes mobile_frontend

※OpenPNEディレクトリのトップで実施

更新:2010/06/23 21:11 カテゴリ: OpenPNE3  > コマンド ▲トップ

No.935 コマンド一覧

./symfony opGenerate:plugin opSamplePlugin
./symfony opGenerate:app opSamplePlugin pc_frontend
./symfony opGenerate:module opSamplePlugin pc_frontend sample

◆プラグインのアンインストール
./symfony opPlugin:uninstall opOpenSocialPlugin

◆プラグインを指定してmigrate
symfony openpne:migrate --target=opMessagePlugin

◆ルーティングルールの確認
./symfony app:routes pc_frontend
更新:2010/06/23 10:35 カテゴリ: OpenPNE3  > コマンド ▲トップ

No.2242 メンテ画面出す方法

メンテ画面出す方法

php symfony project:disable prod pc_frontend
poject:disable タスクを実行すると出せます
php symfony project:enable prod pc_frontend
: で戻せます

data/pc_frontend_prod.lck
ができる
更新:2010/03/31 02:44 カテゴリ: OpenPNE3  > コマンド ▲トップ

No.2097 11.マイグレートスクリプト

11. マイグレートスクリプト

このチュートリアルは、前回で一旦リリースを迎えて
今回から新機能の実装と、バグの修正などを行っていくという
フェイズに入りました。

そこで、改善する前にひとつ、大きな問題があります。
それはデータベースモデルです。

リリース後にユーザによってインストールされ、その時に作成されたテーブルを変更することは
利用者にとっても、開発者にとってもリスクの伴う作業となるでしょう。

そこで、OpenPNEではテーブルに変更がある時に、プラグインごとのリビジョン番号のついた
「マイグレートスクリプト」を作成し、マイグレートスクリプトに付けられた
リビジョン番号によって、データベースの状態の管理を行います。

変更計画

まずは、変更計画を考えなくてはなりません。

3. プロジェクト内で後半部で対応する機能の中に、公開範囲の設定という項目があります。

現行のモデルでは対応することはできませんので、
以下の事を行うマイグレートスクリプトを用意することにします。

  • VoteQuestionへ、public_flagフィールドを追加

新データモデルをschema.ymlへ書き出す

マイグレートスクリプトを書き出す前に、変更後のモデルなどを
schema.ymlに書き出しておきます。
なぜ、これを最初にやるかというと、マイグレート実行時は、テーブルの変更前に
モデルクラスなどの更新を行うためです。
つまり、テーブルの内容の書き換えなどをマイグレートスクリプトで行う事を
想定すると、先にこのファイルを変更しておかないと整合性が取れなくなってしまいます。

plugins/opVotePlugin/config/doctrine/schema.yml の一部

VoteQuestion:
actAs: [Timestampable]
columns:
id: { type: integer(4), primary: true, autoincrement: true }
member_id: { type: integer(4), notnull: true }
title: { type: string(140), notnull: true, notnull: true}
body: { type: string }
public_flag: { type: integer(1), notnull: true, default: 1 }
relations:
Member: { onDelete: cascade }

マイグレートスクリプトを作成する

マイグレートスクリプトはプラグインの data/migrations
に設置します。さらに、そのディレクトリ下はバージョンごとに分けることができ
data/migrations/バージョン/ に置くことが望ましいでしょう。

opVotePluginは、次回バージョンを 0.9.1 としたいので

plugins/opVotePlugin/date/migrations/0.9.1/

を作成します。
その下に、リビジョン番号(三桁)_スクリプト名.php
というファイルを作ります。

今回は、このプラグインにとって初めてのマイグレートスクリプトなので、リビジョン番号は001です。
スクリプト名は任意のものにしてください。
今回は以下の名前を使うことにします。

plugins/opVotePlugin/date/migrations/0.9.1/001_add_public_flag_column.php

スクリプトの内容は、Doctrineのマイグレーションに利用するものと同じです。
以下を確認してください。

Doctrine – Chapter 24 Migrations

今回はカラムを追加するだけで済むので以下のようになるでしょう。

01 <?php
02  
03 class opVotePlugin1_AddPublicFlagColumn extends Doctrine_Migration_Base
04 {
05   public function migrate($direction)
06   {
07     $this->column($direction, 'vote_question', 'public_flag', 'integer', 1, array(
08       'notnull' => true,
09       'default' => 1
10     ));
11   }
12 }

このとき、マイグレートスクリプトごとに1クラスとなりますが、
他のマイグレートスクリプトで利用しているクラス名とコンフリクトすると非常に厄介な事になります。

そこで、プラグイン名のあとにリビジョン番号_マイグレート名 (opOpenSocialPluginの場合)
単に、プラグイン名Versionリビジョン番号 (opDiaryPluginの場合)
というクラスの命名方法が良く使われています。

新規インストール者のための準備

さて、ここで新規インストールを行うと、上のschema.ymlで設定された内容によって
データベースがセットアップされます。
しかし、このままではリビジョン番号を記録していないので、上で用意したマイグレートスクリプトが
実行されてしまいます。

そこで、セットアップ時に挿入されるfixturesを使ってリビジョン番号を最初から
挿入することにします。

plugins/opVotePlugin/data/fixtures/000_revision.yml

SnsConfig:
opvoteplugin_current_revision:
name: "opVotePlugin_revision"
value: 1

見て分かる通り、リビジョン番号はSnsConfigで管理されます。
このファイルはマイグレートスクリプトを作成するごとに更新することを忘れないようにしてください。

マイグレートテスト

テストで繰り返しマイグレートスクリプトを実行したいとき、ブランチを作成してmasterと作成したブランチとの間を行き来する方法が有効と言えるでしょう。
プラグインのディレクトリ下で

$ git checkout -b migrate1

と、「migrate1」ブランチを現在のブランチ(master)から作成し、移動するコマンドを実行します。

$ git add .
$ git commit -m "added migrate script"

今までの変更をすべて追加し、コミットします。

マイグレートスクリプトの実行の前に
比較のため、これまでの状態のDBの状態を確認しておくと良いでしょう。


mysql > DESC vote_question
+-------------+--------------+------+-----+---------+----------------+
Field Type Null Key Default Extra
+-------------+--------------+------+-----+---------+----------------+
id int(11) NO PRI NULL auto_increment
member_id int(11) NO MUL NULL  
title varchar(140) NO   NULL  
body text YES   NULL  
created_at datetime NO   NULL  
updated_at datetime NO   NULL  
+-------------+--------------+------+-----+---------+----------------+

マイグレートを実行します。以下のコマンドをOpenPNEのディレクトリで行ってください。
このとき、–targetオプションと、–no-update-pluginオプションを指定します。
–targetは指定したプラグインのみのマイグレートを行うためのものです。他のプラグインの影響を避けることができます。
–no-update-pluginは、マイグレート時に行われるバンドルプラグインの同期作業などを省略することにより、実行時間を短縮するために付加します。

$ ./symfony openpne:migrate --target=opVotePlugin --no-update-plugin

mysql > DESC vote_question
+-------------+--------------+------+-----+---------+----------------+
Field Type Null Key Default Extra
+-------------+--------------+------+-----+---------+----------------+
id int(11) NO PRI NULL auto_increment
member_id int(11) NO MUL NULL  
title varchar(140) NO   NULL  
body text YES   NULL  
created_at datetime NO   NULL  
updated_at datetime NO   NULL  
public_flag tinyint(4) NO   1  
+-------------+--------------+------+-----+---------+----------------+

マイグレート成功です!

成功したので、masterにmigrate1ブランチを取り込みましょう。

$ cd plugins/opVotePlugin
$ git checkout master
$ git merge migrate1

失敗した時

マイグレートスクリプトを見直し、もう一度やりなおします。
この状態のとき、ブランチを切り替え、データベースを作りなおすことにより
前の状態に戻ります。

$ git checkout master
$ cd ../../
$ ./symfony doctrie:build --all --and-load

マイグレートスクリプトを書きなおすために、先程まで作業していたブランチに
戻ります。

$ cd plugins/opVotePlugin
$ git checkout migrate1

マイグレートスクリプトを書き直し、再びマイグレートを実行してテストしてください。

マイグレート時にデータを挿入する

今回は、実際には行いませんがマイグレートスクリプトの実行時に
データを挿入することもできます。

その方法は、非常に簡単で、マイグレートスクリプトを用意し、
そのスクリプトのあるディレクトリ下に fixtures/ ディレクトリを作成します。
その中に

リビジョン番号_マイグレート名.yml

というymlファイルを用意し、初期データ用のフォーマットと同じように
データベースに挿入する項目を用意してやるだけです。

リスク

素晴らしいマイグレートスクリプトを用意しても、データベースの構造を変える以上
データを破壊してしまったり、正常に動かなくなるというリスクを伴います。
できるだけデータベース構造を変更しない設計をするのはもちろんですが、
安定版・開発版という別々のバージョンをリリースするのもひとつの手でしょう。

尚、OpenPNE3本体では、データベース構造の変更は原則として開発版でしか
行わないというルールが存在します。

引用元

更新:2010/02/16 10:26 カテゴリ: OpenPNE3  > コマンド ▲トップ

No.1091 プロペル時代のアップロードコマンド

プロペル時代のアップロードコマンド

svn up
symfony openpne:migrate
symfony cc
symfony clear-controller
更新:2009/06/26 18:02 カテゴリ: OpenPNE3  > コマンド ▲トップ

No.900 ヘルプ

SF help opGenerate:module
更新:2009/05/11 21:19 カテゴリ: OpenPNE3  > コマンド ▲トップ
8件中 1 〜 8 表示  1 

FuelPHP

Mac

web開発

プロマネ

マネタイズ

プレゼン

webサービス運用

webサービス

Linux

サーバ管理

MySQL

ソース・開発

svn・git

PHP

HTML・CSS

JavaScript

ツール, ライブラリ

ビジネス

テンプレート

負荷・チューニング

Windows

メール

メール・手紙文例

CodeIgniter

オブジェクト指向

UI・フロントエンド

cloud

マークアップ・テキスト

Flash

デザイン

DBその他

Ruby

PostgreSQL

ユーティリティ・ソフト

Firefox

ハードウェア

Google

symfony

OpenPNE全般

OpenPNE2

Hack(賢コツ)

OpenPNE3

リンク

個人開発

その他

未確認

KVS

ubuntu

Android

負荷試験

オープンソース

社会

便利ツール

マネー

Twig

食品宅配

WEB設計

オーディオ

一般常識

アプリ開発

サイトマップ

うずら技術ブログ

たませんSNS

rss2.0