CakePHP3でのマイグレーションについて最低限の事だけ書いておく
参考
http://book.cakephp.org/3.0/ja/migrations.html http://qiita.com/ran/items/c45d0228858accea0e86
まずは現在のステータスを確認
bin/cake migrations status
マイグレーションファイルを作成する 引数にカラム名と使える方を渡しておくと雛形作ってくれる
bin/cake bake migration CreateUser name:string age:integer birthday:date time
/app名/config/Migrations/以下にマイグレーションファイル作ってくれる
マイグレーション実行
bin/cake migrations migrate
マイグレーションはバージョン管理されてるのでロールバックとか出来る
bin/cake migrations rollback
カラムの変更をしてみる
動詞(DDL)->対象カラム->TBL名 targetのカラム名
bin/cake bake migration RemoveBirthdayUser birthday
基本的なアプリケーション実装のライフサイクルは tbl作成 -> tbl情報をもとにbakeでcontrollerとmodelを作成するっぽい
CakePHP3でのリクエストパラメータの取り方
基本的な事
HEADER
$this->request->header('X-HOGE');
POST
$this->request->data('postのキー'),
リクエスト(URL)パラメータ
- アプリケーション側で名前つきで扱いたい時のマッピング
/config/routes.php
に
$routes->connect('/hoge/foo/:bar_number', ['controller' => 'Good', 'action' => 'bad']);
/hoge/foo/123 でアクセスされた時に GoodControllerのbadアクションが呼ばれて、
$this->request->param('bar_number');
で取得できる。
GET
$this->request->query('getのキー');
ElasticBeanstalkでEnvironmentsが削除出来ない時
Deleting security group named: *** Reason: Group *** is used by groups:
のようなメッセージが出てしまいEnvironmentsが削除出来なくてハマった。
直接セキュリティグループを探し当てて削除しようとしても 「使ってるからダメ」と言われる。
どうすりゃいいんだ。。。
と思ってたら
対象EnvironmentsのセキュリティグループがRDSのセキュリティグループに入ってるからだった。 (接続許可リスト) 他にもElasticCacheとかで疎通させててもダメみたいだ。 という事で開通リストから対象のセキュリティグループを削除して解決。
なんとまあ。。。めっちゃハマった。 どこで使われてるのかせめて教えてくれよ。。。
phpで稼働しているサービスを32bitから64bitに移行してハマった事
php5.3系のサービスをRedhat系32bitから64bitへ移行した際に若干はまった
「phpのarray_sliceやarray_mergeで配列から配列を生成した際にキー値が消失する」 という内容だった。
データを覗いてみるとキー値にintegerを指定してた。
上記の関数はキー値が振られ直すので
http://php.net/manual/ja/function.array-merge.php
そもそも使い方が悪い。というのが前提なのだが 「旧環境では動いてたんじゃ!」と言われると原因を話さないとどうにもならない。
って事で調べてみた。
結論
という仕様のためだった。
http://jp.php.net/manual/ja/language.types.array.php http://d.hatena.ne.jp/hnw/20070521
要するに32bit時にはPHP_INT_MAX(2147483647)以上の値をたまたまキーとして指定してたからキーが消失しなかったんだけど、64bitのinteger上限値が9223372036854775807となってしまい、 数値として扱われるようになって関数を噛ました瞬間に添字が振り直されてしまった。
多分余り役に立たない内容だけど、 何かの足しになるかも。と思って記しとく。
ec2sshを試してみた
結論
チョー便利。
大まかには作者のブログに乗ってるんですが一部訂正が必要だったので。
http://blog.mirakui.com/entry/20101205/1291551625
概要
中身はgemのライブラリです。
sshでec2に接続する時は
~/.ssh/config
を設定して
ssh app1
とかでつなぐと思いますが。
ec2はstopするとipが変わって一々書き換えるのが面倒くさい。 それを
ec2ssh init
ec2ssh update
の二回だけで全部のconfigを作ってくれる。
initは最初だけだから実質 「ec2に繋がらんな」と思ったら updateするだけで済む。
まじで便利。 これは色々流用出来そう。
導入
インストール
gem install ec2ssh
以上。 自分はbundler使ってる。
環境変数を設定
export AMAZON_ACCESS_KEY_ID="..." export AMAZON_SECRET_ACCESS_KEY="..."
イニシャライズ
ec2ssh init
bundlerだったら
bundle exec ec2ssh init
設定読み込み
ec2ssh update
元記事だとこれで行けるんだけど。
Set aws keys at ~/.ec2ssh
と出る。
何か設定ファイルが必要みたいだから開いてみると。
vim ~/.ec2ssh
--- path: ~/.ssh/config aws_keys: default: access_key_id: secret_access_key: regions: - ap-northeast-1
yamlファイルだった。
アクセスキーと シークレットキーをセットして。
ec2ssh update
キター
という事で
export AMAZON_ACCESS_KEY_ID="..." export AMAZON_SECRET_ACCESS_KEY="..."
これは不要みたい。
作者のgithubを読んだらちゃんと変わってた。
configに書き込まれたログがダーっと流れて。 configに書き込まれたと思います。
configが上書きされるので 心配な人は念のためバックアップ取っておいた方が良いと思います。 configを入力補完させれば完璧。
ちゃんとec2インスタンスに解りやすい名前を付けようと思った次第です。 これからは
- インスタンスstop or start
- ec2ssh update
これで完璧。
デプロイとかに流用出来そう。
他にも
configに設定する
- IdentityFile
- user
とかも指定出来るから
作者のgithubを見てみると良い。
AWSのc3.largeがお得なんだけどAvailabilityZone内でいっぱいだった
時間が解決してくれるたらこの記事は役に立たないけど。
c3.largeはとってもお得なので現在特定のZoneで作れないみたいだ。
We currently do not have sufficient c3.large capacity in the Availability Zone you requested (ap-northeast-1c). Our system will be working on provisioning additional capacity. You can currently get c3.large capacity by not specifying an Availability Zone in your request or choosing ap-northeast-1a.
まあ諦めて待ちましょう。