忍者ブログ

STEP UP BLOG

Home > ブログ > Laravel4

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

Laravelのマイグレーションロールバック

LaravelはRuby on Railsの精神をPHPでも！という方針で作られたフレームワークです。
したがってRuby on Railsの機能をいくつも受け継いでいます。
そのひとつがDBのテーブル定義に使われるマイグレーションです。
マイグレーションを利用すると、テーブル定義をPHPで記述出来るので、
特定のDBの仕様に依存せずに汎用的な定義をすることが出来ます。
また、テーブル定義の変更を履歴として持っているので、
特定の時間のテーブル定義に戻すこともロールバックで簡単に出来ます。
今回はそのLaravelのロールバックについてです。


Laravelのマイグレーションの基本はmigrationsテーブルです。
マイグレーションを実行すると、migrationsテーブルに実行したマイグレーションファイルが登録されます。
migrationsテーブルのカラムはmigrationとbatch。
migrationがファイル名で、batchが何回目のマイグレーションで実行したかの実行順となっています。
ロールバックするために
$ php artisan migrate:rollback

を実行すると、
batchが最も大きい、すなわちいちばん新しく実行したmigrationファイルのdown()を実行します。
そしてmigrationsテーブルからもそのデータが削除されます。
原理としてとてもシンプルです。


そのLaravelのマイグレーションについて、あるとき問題に気付きました。
Laravelのマイグレーションはmirationsテーブルとマイグレーションファイルの2つが揃っていることが前提です。
もしロールバックしようとして該当するマイグレーションファイルが存在しなかったらどうでしょう。
ロールバック出来なくてエラーとなります。
えー、でもファイルが無いとかあるの？？
だって、ロールバックするには既にマイグレーション実行してなきゃいけないわけですよね。
しかしです。
しかし、gitで管理していてブランチをたくさん作っていると、
いろんなブランチにマイグレーションファイルが分散してしまう可能性があります。
でも他のブランチでわざわざロールバックすることなんてないでしょ。。
まあ、ないですよね。。
でも万が一が考えられます。
本当に万が一ですが。。
どのブランチでもmigrationsテーブルの内容とマイグレーションファイルを一致させておきたい。
その解決のひとつとして、
マイグレーション専用のブランチを作って、
どのブランチもそのマイグレーション専用ブランチを取り込むなどはどうでしょうか。
でもこのようにロールバックに失敗するシチュエーションなんてないですよねえ。。。
PR

Laravel4.2でのファイル入出力

毎年、9月の終わり頃は季節の変わり目なのか体調を崩すのですが、今年も例に漏れず体調を崩してしまいました。
というわけでLaravelはWebアプリケーションのためのフレームワークでありますが、ファイル入出力ももちろんできます。
場合によってはDBに保存するだけでなく、ファイルに出力したり、ファイルからデータを取り込んだりするシーンも出てくると思います。
そのときに役に立つのが、Filesystemクラスです。

http://laravel.com/api/4.2/Illuminate/Filesystem/Filesystem.html

ファイル関連の処理をすべてラッピングしてくれて、煩雑な処理を見通しの良いコードに変えてくれます。
いくつか挙げていくと、
File::append('./abc.txt', 'hello!');

モードを指定して開くとかしなくてもappendで追記できます。
File::move('./abc.txt', './new_abc.txt');

ファイルの移動も
File::copy('./abc.txt', './new_abc.txt');

複製も簡単です。
File::extension('./abc.txt');
拡張子だって、Filesystemなら、ほらこの通り。
PHPのファイル入出力で検索しても出てくるのはネイティブのPHP関数を使ったものが多く、
確かにそれは基本中の基本なんですが、新しいフレームワークを使っているのだからそこもモダンに実装したいところ。
LaravelではそのためのFilesystemなので、ガシガシ使っていきましょう。

Laravel4.2での認証の切り替え(続編)

Laravel4.2での認証の切り替え

http://capella.3rin.net/Entry/25/

の続きです。
前回の実装では、片方でログインした場合、
条件によってはもう片方にもログインしていることが判明しました。
これはまずい。。。
原因はログインに用いられるセッションが同一ということらしいです。
というわけでセッションも切り分ければいいはずなので、
そのへんの設定を教えてもらいましたm(_ _)m
public/index.php内で特定のリクエストのみ
Config::set('session.cookie', 'alternative_laravel_session');
Config::set('auth.model', 'AlternativeModel');
$auth = Auth::createEloquentDriver();
Auth::setProvider($auth->getProvider());

とすれば大丈夫。
なるほど、cookieの名前を変えるんですね。
Laravelマスターへの道は険しい。。。

Laravel4.2での認証の切り替え

Laravelをそのまま使おうとすると、
認証でひとつのテーブルしか設定することができず、
例えばURLによって認証に用いるモデルを切り替えるとかできません。

そこでいくつかの方法が考えられており、そのひとつが以下のパッケージを使うこと。

https://github.com/ollieread/multiauth/

ここまで大袈裟なのは要らないというなら、
認証モデルの切り替えが必要なコントローラなどで、
Config::set('auth.model', 'AlternativeModel');
$auth = Auth::createEloquentDriver();
Auth::setProvider($auth->getProvider());

としてapp/config/auth.phpの内容を書き換えるのも手です。

このような認証の切り替えはよくあることなので、
Laravel本体だけでなんとかしてほしいものですね。。

Laravel5については以下が参考になります。

http://qiita.com/zaburo/items/bc699185b6de12c0413d

LaravelでのCSRFフィルターとトークン

http://laravel.com/docs/4.2/html#csrf-protection

LaravelではCSRFフィルターを通すとトークンチェックが行われます。
フォームで送信されたトークンが正しいかチェックするというものです。
普通にForm::open()をするとトークンは自動的にhiddenのinputタグで埋め込まれるのですが、
AjaxでPOST送信などするときに、何も考えずに送信するとTokenMismatchExceptionが発生します。
そんなときはForm::token()でトークンを明示的に追加することで回避できます。
        
  • 1
  • 2

PAGE TOP