MySQLのトランザクションは、処理の途中で失敗した場合に ROLLBACK（ロールバック）で元の状態に戻せる便利な仕組みです。
しかし「必ず元に戻せる」と思っていると落とし穴にはまります。

実は、MySQLには ROLLBACKが効かない（厳密には「元に戻せない」）SQL文 が存在します。

ROLLBACKできるSQL（DML）

一般的なデータ操作言語（DML）はトランザクションで管理でき、ROLLBACKも可能です。

• INSERT
• UPDATE
• DELETE

これらは通常通り、トランザクションの途中で ROLLBACK すれば元の状態に戻せます。

ROLLBACKできないSQL（DDL）

一方、スキーマを変更するようなデータ定義言語（DDL）は注意が必要です。

• CREATE
• DROP
• ALTER
• TRUNCATE

これらのDDL文を実行すると、MySQLでは 暗黙的に COMMIT が発生 します。そのため、実行後に ROLLBACK しても元に戻すことはできません。
つまり「ROLLBACKがエラーになる」のではなく、「DDLが実行された時点でトランザクションが確定してしまう」イメージです。

他のデータベースとの違い

これはMySQL固有の挙動です。
データベースによってはDDLもトランザクション管理下に置ける場合があります（例：PostgreSQLでは多くのDDLがトランザクション内でROLLBACK可能）。

MySQLを使う際には「DDLは必ず即時確定する」と覚えておくのが安全です。

まとめ

• INSERT / UPDATE / DELETE はトランザクションで管理でき、ROLLBACK可能
• CREATE / DROP / ALTER / TRUNCATE は実行時に自動コミットされ、ROLLBACK不可
• ROLLBACK自体がエラーになるわけではなく、「巻き戻せない」だけ
• PostgreSQLなど他のDBではDDLもROLLBACK可能な場合がある

参考： MySQL公式ドキュメント – ステートメントをロールバックできない場合

gitを使ってソース管理し開発をしていて、差分ファイルをリリースするときのTipsです。

差分を抽出する

git diff [古いブランチ名]..[新しいブランチ名]
git diff [古いブランチ名] [新しいブランチ名]

ファイル名だけを列挙したいとき

git diff --name-only [古いブランチ名] [新しいブランチ名]

ファイル名のリストをテキストファイルにリダイレクトで書き出す

git diff --name-only [古いブランチ名]..[新しいブランチ名] >> diff.txt

ブランチをアーカイブ出力

git archive [ブランチ名] -o archive.zip

出力するディレクトリを指定

git archive --prefix=archive/ [ブランチ名] -o archive.zip

差分抽出とアーカイブ出力を組み合わせて、抽出した差分ファイルをアーカイブ出力

git archive --prefix=archive/ [新しいブランチ名] (git diff --name-only [古いブランチ名] [新しいブランチ名] --diff-filter=ACMR) -o diff.zip

小文字にすると逆になるので、以下のようにしても同じことになります。

git archive --prefix=archive/ [新しいブランチ名] (git diff --name-only [古いブランチ名] [新しいブランチ名] --diff-filter=d) -o diff.zip

CSVファイルで各カラムがダブルクォーテーションで括られていないことがたまにあります。
そんな時、皆さんどうしていますか？
私はテキストエディタでカンマ「,」を「”,”」に置換し、行の先頭と末尾にダブルクォーテーションを付ける・・・ということをいちいちやっていました。
しかし、PowerShellのコマンドを使えば、一発で簡単にダブルクォーテーションを付けることが出来るようなのです。

コマンド例はこちら

Import-Csv -Path "C:\source.csv" -Encoding Default | Export-csv -Path "C:\destination.csv" -Encoding Default -NoTypeInformation

インポートしたCSVの内容をパイプでエクスポート側に渡す、という動作になります。

変換元のCSV

ColumnA,ColumnB,ColumnC
1,Ipsum,Sed
2,Magna,Est
3,Clita,Stet

変換後はこのようになります。

"ColumnA","ColumnB","ColumnC"
"1","Ipsum","Sed"
"2","Magna","Est"
"3","Clita","Stet"

但し、数値のカラムに対してもダブルクォーテーションが付けられるので、そこは我慢するしかないようです。

PHPのバージョンを7.4系から8.x系にバージョンアップする事案があり、変更点やシステムの動作に問題がないか等の調査をしていました。
その中で公式ページにも見当たらないことがあったので、実際にバージョンを切り替えながら検証して分かったことを共有させていただければと思います。

今回発見した問題点はPDOのプリペアドステートメントです。
セキュリティ上、脆弱性のないように開発する中で必ず使われているかと思います。

ただ、このプリペアドステートメント、数値型のデータを文字列型で返してきます。
困りますね。
しかしながらそういう仕様なので、それに合わせてコーディングするしかないわけなんですが、
これがなんと、8.1以降だと数値型で返ってるのです。

なんということでしょう・・・。

厳密な比較を行っている箇所はすべて修正しないといけません。
例えば以下のような場合です。

if($col["COLUMN_NAME_INDEX"] === "1") { ... }

このCOLUMN_NAME_INDEXのデータ型は数値型（Integer）ですが、PDOのプリペアドステートメントで返ってくるのは文字列型のため、このような比較をしています。
これが8.1以降だとCOLUMN_NAME_INDEXのデータが数値型のため、(1 === "1")という式となり判定はfalseとなります。

この問題については、コーディング自体に間違いがあるわけではありませんので、コード解析ツール等にかけても出てこないと思います。
原因の究明に時間がかかったので、ここに記しておきます。

更に調査したところ、PDOの設定でエミュレート・モードというものがあり、有効/無効（true/false）で設定します。
実際には今回の件に関する具体的な設定ではないのですが、この設定を無効（false）に設定してみると8.0でも数値型で返ってきました。

PDO::setAttribute(PDO::ATTR_EMULATE_PREPARES, false)

検証したバージョンは次の通りです。
7.4.29
8.0.28
8.1.17
8.2.4

また、逆に従来の文字列に合わせる場合だと確実に動作させることができます。
PDO::ATTR_STRINGIFY_FETCHESオプションをtrueにすることで全て文字列で返すように設定することが可能です。
公式リファレンスにも「全てのフェッチする値を強制的に文字列として扱います。」と書かれています。

PDO::setAttribute(PDO::ATTR_STRINGIFY_FETCHES, true)

公式：PHP 8.0.x から PHP 8.1.x への移行

Invoke-WebRequestとcurlコマンドを使えばCUI（Commandline User Interface）にてHTTPリクエストを送信することができます。
ここでは基本的な使い方をご紹介します。

Windowsの場合

まずはWindowsの場合です。
PowerShellでInvoke-WebRequestコマンドを使います。

このコマンドにはエイリアスが設定されており、curl iwr wgetでも使えます。
curlはあくまでエイリアスなので、Linux・Macでのcurlとは異なりますのでご注意ください。

GETリクエスト

Invoke-WebRequest https://www.hoge.jp
Invoke-WebRequest -Method GET https://www.hoge.jp

パラメータを付加したリクエスト

Invoke-WebRequest https://www.hoge.jp?key=value&key=value
Invoke-WebRequest -Method "GET" -Body @{key="value";key="value"} https://www.hoge.jp

POSTリクエスト

Invoke-WebRequest -Method "POST" -Body 'key=value&key=value' https://www.hoge.jp
Invoke-WebRequest -Method "POST" -Body @{key="value";key="value"} https://www.hoge.jp

続きを読む…»