読者です 読者をやめる 読者になる 読者になる

MySQLのint(3)とかint(10)とかint(50)とか

今日ふと見たschemaで、

letter varchar(16) DEFAULT NULL,

みたいのがあった時に、違和感があった。

この(16)っていう桁数って意味あるんだっけ・・?
なんか使われる領域は結局同じだったような・・?

結論から言うと、これは勘違いでした。
この違和感はint型の時のやつでした。

以下、実験コード。

gist0a701d3a4ba4c6c10331

create database test_lengthしてから
mysql -u root test_length < length_test.sql で食わせてください。

結果は

mysql> select * from varchar_length;
+----+------------------+-------------------+
| id | letter016     | letter256     |
+----+------------------+-------------------+
| 1 | 1234567890123456 | 1234567890123456  |
| 2 | 1234567890123456 | 12345678901234567 |
+----+------------------+-------------------+
2 rows in set (0.00 sec)

こっちは、ある意味想定通り。
16桁のところには、17文字目以降は入らない。
一方int型の

mysql> select * from int_length \G;
1. row
id: 1
number03: 100
number10: 100
number50: 100
number03_fill: 100
number10_fill: 0000000100
number50_fill: 00000000000000000000000000000000000000000000000100
2. row
id: 2
number03: 1000
number10: 1000
number50: 1000
number03_fill: 1000
number10_fill: 0000001000
number50_fill: 00000000000000000000000000000000000000000000001000
2 rows in set (0.00 sec)

違和感は原因はこの時のやつでした。
MySQLのint型の時には別に領域はそのままで表示の桁埋めのための表記ということ。
int(3) にしても1000は入るし、int(50)なんてのもできてしまう。

MySQL createtable int zerofill」あたりでググると色々でてくる。

戻ってまとめると、varcharの容量とか仕様のために桁数を検討することは正しい。

phpのsyntax checkとperlのuse check テスト

リポジトリ配下のファイルの内容を最低限保証するためのテストを書きました。
PHPで調べたところ、syntaxをチェックするそれっぽい関数がない。

正確に言うと、過去にはphp_syntax_checkというのがあったようだけど、5.0.5という結構な昔に廃止された模様。
代わりにコマンドラインから php -l hoge.php が推奨らしい。

なるほどーと思いつつ、推奨されてるならその通りに従って書いてました

php syntax check test

libというディレクトリ配下全般をチェックする前提です。
ファイル一覧を取得するのは1個前のエントリと変わらず。

ちなみにPerlでやろうとすると、perl -wc hoge.plになるんだろうけど、
リポジトリ配下に対してというアプローチの場合、pmファイルを対象としているハズ。
pmファイル群つまり各モジュールがloadできるかをチェックしたいという意図になると思うので、それに対しては Test::Moreの use_okによって実現できる

perl module use_ok test

本当はPHPの場合もロードが正しくできるかをチェックしたかったのだけど、前述のだとそこまでは見られない。
ただ、PHPにおいては vendor/autoload.php でドバっと読み込むのが主流っぽい気もするし、 Perl のように各個ごとに use を並べるのとは仕組みが違う気もするので、今回はこの形に落ち着きました。 

PHPでcrontabを意図通り書けているか確認するテストを書く

以下の環境と状況を前提にします

  • あるリポジトリにcrontabに設定したい内容をtxtファイル( cron.txt)を含めてコミットしている
  • コミットされたファイルがデプロイされるとその内容に基づいてデプロイ先サーバーでcrontabが設定される

よくある構成かと思います。
ここでコミットされているファイルに以下のような記述がありました。

* 13 * * * php hoge.php

この設定を書いた意図は、「毎日13時に hoge.phpを起動したい」でした。
しかし実際の挙動は「毎日13時台に毎分 hoge.phpが起動する」になります。

これに気づかないままコミットしてデプロイされてしまうと、本番サーバーに異常な負荷がかかったり、データ不整合が起こる可能性があります。

このリスクを少しだけ減らすためのテストを書きました。

php_cron_test

cron-expressionというパーサーがあったのでこれを用いています。
便宜的に $PROJECT_ROOT/cron_file 配下に cron.txt(群)がある想定とします。
その上でcron.txt内のcrontabの宣言の次に以下の2行を追加します。

  • ###prev YYYY-MM-DD HH:ii:ss
  • ###next YYYY-MM-DD HH:ii:ss

まず、「cron宣言の後にこの2行がないと落ちる」テスト項目が書かれています。
なので、ファイル内のすべてのcron宣言の後に2行追加する必要があります。
追加した2行には「2015年1月1日 0時0分0秒」から見て、

  • prev : 最も直前にcronが動いた時間
  • next : 最も直近でcronが動く予定の時間

を書きます。前述のパターンの場合だと、こんな感じです。

* 13 * * * php hoge.php
###prev 2014-12-31 13:00:00
###next 2015-01-01 13:00:00

つまり、「メモ書きを追加することで『設定した時間が意図通りか』をある程度まで自己確認すること」を目的としたテストです。
実際に、prevの設定値を「2014-12-31 13:59:00」にするか、
cronの宣言を「0 13 * * * php hoge.php」にしないとテストが落ちます。

試しに作ってみた系なので、色々問題はあるかと思っています。

  • cron.txtが汚れる
    • 嫌がる人は嫌がる
  • 意図とはズレていても結果的に期待値が同じprevとnext指定になるケースもきっとある
    • cron-expressionが指定時間からの前後時間を返すメソッドを用意してるためそれに合わせた仕様にしたのでこれは許容
  • 基準日だったり、パース用のprefixは割と適当
    • なので変更してもらって構わない

PerlだとTest::Crontab::Formatがあり、 これはcron.txtに余計な記述をすることなくcrontabのformatをチェックできるので便利です。
最初はこれっぽいものを探していたのですが、見つからなかったのと今回遭遇したケースは 「意図と違う時間の設定 = うっかりミス」だったので、こういうアプローチにしてみました。