PDOのFETCH_CLASSがprivateなプロパティでも使えるのは便利なのか気持ち悪いのかよくわからない
PHPでデータベースを操作する際に、
私は基本的にPDOを使用しています。
PDOには、fetchしてきたデータを指定したクラスに
勝手に詰め込んだオブジェクトを返してくれる
PDO::FETCH_CLASSというオプションがあります。
いかにも便利そうなんですが、
何となく思い込みというか常識的に考えて、
データを詰め込むモデルのプロパティは
privateにしてあるからFETCH_CLASSとか使えないんじゃね、
と思い込んでいました。
しかし、今日調べ物をしていて偶然見つけたんですが、
privateなプロパティでも勝手に詰め込んでしまうんですね。
PDO::FETCH_CLASS and visibility private (private constructor, private property)
https://bugs.php.net/bug.php?id=44337
実験してみたら確かにprivateなプロパティにも勝手に詰め込まれいましたし、
またプロパティは当然privateのままでした。
EC2の小ネタ三つ
今日はEC2を使う上で知っておくと何かと便利なネタを三つほど紹介します。
といっても、リンクを三つ張るだけの簡単なお仕事ですが。
"Auto Scaling"で指定時刻にEC2インスタンスを起動
http://blog.suz-lab.com/2011/08/auto-scalingec2.html
EBS-backedインスタンスのrootボリュームをサイズ増量
EC2インスタンスにEBSボリュームでRAID0環境を作る
PHPのmktimeは引数の順番がイミフなのでDateTimeを使いたい。
PHPを使っていて結構困ることの一つに
mktimeの引数の順番があります。
どんな順番で並べたらいいかだいたい忘れていて、
いつもphp.netのお世話に。
ということで、PHP5.2以降だとDateTimeクラスが使用できるようになっているので
多少めんどくささが緩和されます。
といっても、まだ本格的にDateTimeを使い倒してはいないんですが。
参考サイトいくつか。
PHPの DateTimeオブジェクトの簡易リファレンス
http://fdays.blogspot.com/2008/03/strtime-phpdatetime-datetime-new.html
DateTimeクラスを使ったモダンな日付処理
DateTime クラス(php.net)
innodbでテーブルごとにデータファイルを作成する
通常、データは単一のibdata1というファイルに保存されます。
このファイルはmy.cnfの設定によって自動拡張するようになっていて、
放置していると平然と数GBとかにふくれあがります。
32bitのLinuxを使用していた場合、2GB以上のファイルは扱えなかったりするので、
ibdata1が大きくなりすぎてMySQLが動かなくなったりするわけですね。
いまどき32bitのLinuxを使用することもあまりないと思うのですが、
EC2のsmall instanceなんかはなぜか32bitだったりするので困りものです。
それに、ひたすらibdata1のサイズが肥大していくのも気分がよくない感じです。
それで表題の話。innodbではテーブルごとにデータファイルを作成することができます。
MySQLの定番サイト、「漢のコンピュータ道」に参考になる記事があります。
InnoDBのファイルサイズ管理
http://nippondanji.blogspot.com/2009/01/innodb_16.html
innodb_file_per_tableの設定をすればよし。
大きくなってしまったibdata1を小さくする方法もあります。
ibdata1 のサイズを減らす手順
http://bitwalker.dtiblog.com/blog-entry-162.html
一回データを消した上で入れ直さないといけないので、
動いているシステムで行うのはちょっと大変です。
mod_rewriteのQSAフラグの存在をよく忘れる件
Apacheにはmod_rewriteというURLをリダイレクトしたりするのに
使える便利なモジュールがあります。
使いすぎるとかなりの黒魔術状態ですが、
やっぱり使ってしまう。
mod_rewriteの簡単な紹介記事は
mod_rewrite サンプル集
http://tech.bayashi.jp/archives/entry/techweb/2007/001981.html
など参考になります。
mod_rewriteは便利なんですが、一つ困ったことがあります。
たとえば、
http://foo.bar/hoge/foo?page=1
みたいなURLをmod_rewriteを使って書き換えた場合、
最初からついてたパラメータ
page=1
が消えてしまうんですね。
んで、元々ついてたGETのパラメータを消さないようにするための仕組みが
QSAフラグというやつで、
こんな感じに使います。
RewriteRule ^hoge/([0-9]+)$ /hoge.php?param=$1 [QSA]
この場合
にアクセスした場合
http://foo.bar/hoge.php?param=1&page=2
というURLにリダイレクトされる、と。
いつも忘れて検索してしまうので、メモっておきます。
PHPのautoloadは結局どう書くのが一番気分がいいのか
PHPにはクラスを自動的に探してくる
オートローディングという機能があります。
オートロードするための関数を登録する方法として
__autoload()とspl_autoload_register()の二つが存在し、
__autoload()は複数の関数を登録できないので非推奨、
spl_autoload_register()を使いましょう、ということになっています。
サードパーティのライブラリなんかを使用する場合、
__autoload()だと困ったことになるわけですね。
で、オートロードの関数を作成するわけですが、
クラスの存在するかもしれないファイルのパスを指定する方法は
だいたい三通りあります。
１．クラスをおいてあるディレクトリを逐一指定してパスを作成する
２．クラスの命名規則からパスを作成する
３．名前空間の命名規則からパスを作成する
１は簡単ですね、/path/to/hogeとかディレクトリを書いておいて、
そこから/path/to/hoge/AClass.phpみたいなパスを作成する。
2はPath_To_Hoge_AClassみたいなクラス名をつけるようにして
そのクラス名を分解して/path/to/hoge/AClass.phpにする。
3はPHP5.3以降の新機能名前空間を使用する方法。
オートロードの関数には補完された名前空間が渡されるので
path\to\hoge\AClass.phpみたいな名前空間からパスを作成する、と。
PHP5.3以前は1か2の方法が使用されていて、pearでは2の方法が推奨というか、
命名規約に書かれています。
http://pear.php.net/manual/ja/standards.naming.php
ただ、私は2の方式の長ったらしいクラス名が嫌いだったので、
めんどくさいと思いつつ1の方法を使用していました。
PHP5.3以降は名前空間が使えるので3の方法にすればいいんじゃね？
という話になるわけですが、補完なしにuse Foo\Barとか打つのはマゾいので
もろもろ検討中です。
