PDOでのマイクロ秒

Question

すみません、初めてマトモな質問をします。よろしくお願いします。

MySQL、PostgreSQLでマイクロ秒のカラムを作り、INSERTするのは出来るのですが、SELECTしてfetchすると秒単位に切り詰められてしまうことに気づきました。

php.netのPDOのマニュアルをざっと見てみたのですが、該当の記述が見当たりませんでした。

PDOでマイクロ秒を取得することは出来ないんでしょうか？

<?php
    $dsn = "mysql:dbname=test_db;port=3306;host=localhost";
    $hdl = new PDO($dsn, "test_user", "testtest");

    if(!$hdl){ echo "could not connect"; exit; }

    $hdl->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $hdl->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
    
    $qry = "DROP TABLE `hoges`";
    $stmt = $hdl->prepare($qry . ";");
    $result = $stmt->execute();
    if(!$result){ echo "drop table failed"; exit; }
    
    $qry = <<< EOL
CREATE TABLE `hoges` (
`idx` INT COLLATE utf8mb4_general_ci NOT NULL DEFAULT 0 COMMENT 'ID', 
`add_at` TIMESTAMP(6) COLLATE utf8mb4_general_ci NOT NULL COMMENT 'add_time', 
PRIMARY KEY `p_hoges`(`idx`)
) ENGINE=InnoDB DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci COMMENT='hogeテーブル';
EOL;
    
    $stmt = $hdl->prepare($qry . ";");
    $result = $stmt->execute();
    if(!$result){ echo "create table failed"; exit; }
    
    $qry = "INSERT INTO `hoges`(idx, add_at) VALUES (1, '2016-03-22 19:38.01.123456')";
    $stmt = $hdl->prepare($qry . ";");
    $result = $stmt->execute();
    if(!$result){ echo "insert failed"; exit; }
    
    $qry = "SELECT * FROM `hoges` WHERE idx = 1";
    $stmt = $hdl->prepare($qry . ";");
    $result = $stmt->execute();
    if(!$result){ echo "select failed"; exit; }
    
    $result = $stmt->fetchAll(PDO::FETCH_OBJ);
    print_r($result);

出力結果

Array ( [0] => stdClass Object ( [idx] => 1 [add_at] => 2016-03-22 19:38:01 ) )

追記：

ふと検索したstackoverflowを見ると、

http://stackoverflow.com/questions/22026570/php-how-to-return-datetime6-from-mysql

かなり古い話ですが、PDOのバグだというような内容が…
まだ治っていないということでしょうか…

Answer 1

MySQLに関しては、以下が関係しているかも知れません。
https://bugs.php.net/bug.php?id=67122

PDO::ATTR_EMULATE_PREPARES = falseのとき、マイクロ秒以下が切り捨てられてしまうそうです。

PostgreSQLについては、それらしい情報を見つけることはできませんでした。

Comments

[退会済みユーザー]

有難うございます、確かに

$hdl->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

だと、マイクロ秒まで取れました。
しかし、これはセキュリティ的にまずですね…

やはり当面はマイクロ秒は無しでいくしかないということですか。

[退会済みユーザー]

PostgreSQLについては他の問題かもしれないので、もう一回テストしてみます。

[退会済みユーザー]

すみません、PostgreSQLでは
$hdl->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
でも、マイクロ秒とれました。

申し訳ありません、別の問題だったようです。

有難うございました。マイクロ病についてはどちらでも動くようにコードを書き換えます。

[mpyw]

PDO::ATTR_EMULATE_PREPARESがtrueでも大して問題ないですよ．charsetがutf8として設定されている限りはなんの問題もないです．PDOが出たての頃は「PHPのエセプリペアドステートメントは信用出来ない」とかいろいろ言われてましたが，最近では問題ないことが分かってきています．

[mpyw]

$dsn = "mysql:dbname=test_db;port=3306;host=localhost";
↓
$dsn = "mysql:dbname=test_db;port=3306;host=localhost;charset=utf8";

[退会済みユーザー]

複文が実行できてしまうのではないですか？

[KiyoshiMotoki]

lucker様、解決されたようで何よりです。

> 複文が実行できてしまうのではないですか？

おっしゃるとおり、PDO::ATTR_EMULATE_PREPARES = true の場合は複文が実行できるようですね。
徳丸氏のブログに詳しい説明がありました。
http://blog.tokumaru.org/2013/12/pdo-and-mysql-allow-multiple-statements.html

しかし、上の記事はプレースホルダを使用せずにクエリを構築した場合の検証結果で、
"対策"の項にも
「この件について特別な対策は必要ありません。」
とした上で具体的な方策を提示されているので、
　PDO::ATTR_EMULATE_PREPARES = true
の場合でも適切にSQLインジェクション対策をおこなえば問題ないのかな？と予想します。

未検証なので恐縮ですが。。

[退会済みユーザー]

KiyoshiMotoki様、ありがとうございました。

かなり前からマイクロ秒が取れないことに気づいていて、時間がとれず検証ができないでいてずっと気にかかっていましたが、おかげですっきりしました。

複文については「適切にSQLインジェクション対策をおこなえば」というところが私のしていることには少々問題で、SQLインジェクションについて全く知らない人でも、手順通りにコードを書けば脆弱性が生まれない事を目指しています。

マイクロ秒が欲しかったのは楽観排他用のタイムスタンプの精度を上げたかったからですが、複文の危険性を容認するくらいなら、秒単位の楽観排他の方が良いと考えています。

[KiyoshiMotoki]

lucker様、ていねいなご返信、ありがとうございます。
お役に立てたなら幸いです。

CertainN様も、情報の捕捉、ありがとうございます。

[mpyw]

複文のことについては知らなかったので助かりました．こちらに追記しておきます．
http://qiita.com/mpyw/items/b00b72c5c95aac573b71#%E3%82%A8%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E3%81%BE%E3%81%A8%E3%82%81

使い方次第で複文からなるプリペアドステートメントは便利になりますね．パフォーマンスもエミュレーションONのほうがよく，同名のプレースホルダを用いて簡単に複雑なSQLが組めるというメリットもあるので，徳丸さんとは逆で私は特別な事情がない限りはエミュレーションONの方を好んで使っています．

>> 複文については「適切にSQLインジェクション対策をおこなえば」というところが私のしていることには少々問題で、SQLインジェクションについて全く知らない人でも、手順通りにコードを書けば脆弱性が生まれない事を目指しています。

「正しくない使い方をする人」の場合はそもそもSQL文をPHPの変数展開で組み立ててしまい，この場合はどうであれ脆弱性は発生してしまいます．「SQLインジェクションが発生してもDROPなど破壊的な命令は実行されない」という気休め程度の保険がつくだけで，例えばブラインドSQLインジェクションでデータの二分探索などは平然と許してしまいます．

>> 複文の危険性を容認するくらいなら、秒単位の楽観排他の方が良いと考えています

「データの破壊は止められるが盗難は防げない」程度の気休めのために機能面での制約を増やす必要があるかどうかは疑問です．

http://dsas.blog.klab.org/archives/52021703.html