コネヒト開発者ブログ

コネヒト開発者ブログ

CakePHP3.4.8にアップデートしました!

f:id:itosho525:20170430222524j:plain

こんにちは。最近は妄想キャリブレーションの『桜色ダイアリー』をヘビロテしているサーバーサイドエンジニアの@itoshoです。

既に3.4.9がリリースされていますが(汗)、先週3.4.8がリリースされましたので、今回も簡単にアップデート内容をまとめさせていただきました。

CakePHP3.4.8の変更点まとめ

今回は以下の変更がありました。

  • composerのkeywordsが改善されました。
  • BelongsToMany::link()関数で複数の操作が正しく持続されない不具合が修正されました。
  • APIドキュメントが改善されました。
  • POファイル解析で同じメッセージキーが定義されている時、コンテキストの有無を問わずメッセージが正しく解析出来るように修正されました。
    • この変更により、翻訳メッセージの内部データが変更されるため、アップグレードする際はi18nキャッシュデータを消去する必要があるようです。
  • ValidationRuleでunpack errorが発生する不具合が修正されました。
  • RouteBuilder::prefix()関数でpathセグメント(prefix routing scopeに使用される)をカスタマイズ出来るようにするためのpathオプションがサポートされました。
  • LoggingでentityのJSONエンコードバージョンがログに記録されるように修正されました。
    • さらにログに記録されたJsonSerializableインスタンスは、Unicodeデータをエンコードしないようです。
  • 他のQuery::matching()関数の中で呼び出されたQuery::matching()関数を使用するページネーションクエリが無効なSQLを発行する不具合が修正されました。
  • AngularJSによって生成されたURLが正しくパースされない不具合が修正されました。
  • MailerでEmail上でのgetter関数が正しくプロキシされない不具合が修正されました。
  • Database\Query::clause()関数が不明なクラスを読み込んだ際にexceptionが発生するよう修正されました。
  • RedisEngine::add()関数はキーを2回書く代わりに、setTimeout()を使ってTTLを出来るようになりました
  • RedisEngine::increment(), decrement()関数はカウンターでTTLをセット出来るようになりました。
    • Memcachedのカウンターと一貫した動作になったようです。
  • Zを使ったISO8601形式の日付データが正しくパースされない不具合が修正されました。
  • ProgressHelper::init(), draw(), increment() 関数は$thisを返却するようになりました。
  • Auto Incrementが明示的に無効になっている場合、MySQLスキーマのリフレクションによって、主キーのカラムが自動的にインクリメントされなくなりました。
  • FormHelper::radio()関数で、オプションが複合フォームで定義され、オプションのサブセットのみがdisabled属性になっている場合に、disabled属性が正しく生成されない不具合が修正されました。
  • TableHelper::output()関数で全ての行が同じキーを持つ必要がなくなりました。

詳細は公式のリリースノートをご覧ください。

また、リリースノートには記載されておりませんが、先日界隈で話題になった ServerRequestFactoryクラス内のextract()関数が予期せぬ不具合を引き起こす可能性がある問題*1修正されております。スピード感素晴らしいですね!

アップデート時にやったこと

リリースノートの項目自体は多かったものの、弊社のプロダクトに影響がありそうな変更はなかったため、今回も composer updateコマンドを実行後、CIが通っていればOKとして、リリースを行いました。 (リリース後も特に問題は発生しておりません)

おわりに

この冴えない連載も気付けば4回目の更新になりました!更にこの連載を育てるべく次回の更新は弊社Superエンジニア@super_mannerがお届けします!

脚注

CakePHP3のORMの中核を担う「Entity」とは何か 〜CakePHP2ユーザー向けに〜

こんにちは、サーバーサイドにコードを放り込んでいます金城 (o0h_)です。

https://cdn.mamari.jp/authorized/594fc0f8-f2e8-49c7-a174-2ce30a0103ab.jpg

週に数回の頻度で「はじめてのメーガン・トレイナー」を聴いています。 まったりする〜


ここのところ、弊社では「社内でエンジニーアズのLTしよーぜ!」をしています。
私も発表する機会があったので、CakePHP3の紹介トークのようなものをしました。

特に「2.xなら触ったことがある!」ような人を意識した内容にして、2.x→3.xの最も目覚ましい変化の1つである「ORM/モデルレイヤーの(大)変革!!」を取り上げました。様々な変更内容がある中、フォーカスしたのは「PHPとデータベース間の、データ形式の変換の流れ」についてです。1

その際に質問を受けたり、自分でも「今までそんなに気にしていなかったかもなー?」という点がいくつか湧いてきました。
今回は、LTを行った内容をベースとしながら、私なりに「CakePHP3のモデルについて」改めて調べた内容を交えて紹介してみたいと思います。
主に前メジャーバージョンである2.xとの比較を意識しながら進めて参ります。


  1. 過去にQiitaにも晒した内容の焼き直しとなりました。社内的に「CakePHP3に触れる面子が増える」という事情があったので、改めて紹介しておくか〜と思ったのが動機です。

続きを読む

今からちょっとだけ先の未来、CakePHP4の話 〜Upcoming CakePHP Roadmap & Releases〜

こんにちは、森の蒸留所に行ってからずっとウイスキー飲みたい金城 (o0h_)です。
今回は、ちょっと小ネタを・・・

次世代のCakePHPの姿が、少しずつ。

先日CakeFestというCakePHPの公式カンファレンスが行われました。

その中でMark Story氏によってCakePHPのロードマップについての講演があったのですが、
私はそれを「未来だ、未来だ!!」と思ってワクワクしながら眺めていたわけです。

www.pscp.tv

さて、その内容が先程Bakeryにアップされました!! 🎉🎉
普段めっきりCakePHP3にお世話になっている弊社エンジニアとしては、この興奮を社(内|外)に少しでも早くおすそ分けしたいな‥?と思うのです。

そこで、本エントリーではBakeryで触れられている内容(+α)を簡単に紹介させてください。

ざっくり言うと

  1. 3.5はこの夏にリリースされる予定だよ。後方互換性はもちろんあるけど、廃止予定なAPIはランタイムエラーを吐くようにするよ
  2. 4.0は2017年の遅くか、2018年にリリースされる予定だよ。PHP7.1+を要求するけど、3.6を使っていれば簡単に移行できるようにするよ(&& 2.x系->3.0のような劇的な変化はしない!)
  3. 3.x系については、4.0.0が出た後18ヵ月はバグ対応をして36ヵ月はセキュリティ対応をする予定だよ
  4. 2.x系については、バグ対応:12ヵ月、セキュリティ対応:18ヵ月を予定しているよ

という内容でしょうか。
ぜひ 原文 を御覧いただきたいです!

姿を見せつつある4.0

Strawberry って言うのですねw 可愛い。1
コンセプトとしての4.0は、 こちらのスライドを是非ご一読ください。

www.slideshare.net

弊社では3.x系と2.x系のプロダクトが混在しているので、どちらも日常的に読み書きしていますが
3.xは書いていて「とても気持ち良いな」と感じています。お気に入り。

・・・とはいえ、2.x系 > 3.0では「非常に劇的」な変化があり、身体感覚に馴染むまでに大きな学習コストと時間を要したのは事実です。。
そのため、「3.6からの移行ハードルを下げる」というのはとても興味深く感じました。2

具体的には「非推奨のものを使っていなければ、ちょっとの手間で動く!」と明記されているので、
こうなると気の重さよりもワクワク感が大きくなってきますよね。

また、「厳密な型制約」についても言及されていて、この点も個人的に非常に目を引かれています。3

PHP全体で言える傾向として、 「簡単に書ける」の意味合いが「間違えても動く」から「間違いにくくなる」にどんどんシフトして行っていると感じる今日このごろです。
その文脈に則って、CakePHP4.0において「ますます今っぽく」なるのかな、という印象を受けます。

さて機能から見る4.0は、一体どんな姿になるのか?についてですが、当該のエントリーではあまり詳しく触れられていません。
気になる方は、4.0 Roadmap · cakephp/cakephp Wiki · GitHubをウォッチしてみてください!

4.0を見据えた3.6

3.6が、実質「3.x系の最後の進化」になるのかもしれません。4

そしてコレも「4.0への移行を簡単にしたいため!」という理由からだそうなので、位置づけとして「橋渡し」的な面があるのかと理解しています。

その3.6ですが、機能的には「Middlewareレイヤーの強化をする!!」というのが個人的な関心でありつつ
もしかすると、それよりも「非推奨のものを使うとランタイムエラーを吐く」というのに目を引かれました。すげぇな。。。5

次点として、「ルーティングを書きやすく」も便利そうだなぁ〜と思っています。 issue#10643を見ると、 例えば/users/:name/users/{name}となっていくのでしょうか。 これは今までよりも直感的だなと思います!6

今後の動向に注目 && 日頃から備えておく

個人的な感覚では、3.0が出たのは割と最近・・・とも思っていたのですが。。
もう具体的な「4.0」の声が聞こえてきつつあります。
どんな面白いコードやエレガントな機能が出てくるかな?と今から楽しみです。
もう少ししたら、次世代CakePHPの開発もいよいよ加速していくと思いますので、これは目が離せません!

また、今回のマイグレーションやそのサポートに関する指針を見て、
改めて「レガシー化させないための最大の武器は、小さなホコリは気付いたら払っておく」ことだと思いました。
弊社では方針として「なるべく最新に追従する」戦略をとってマイナーアップデートも積極的に行っています。
これは、小さな修正でも溜め込んでいくと「移行」自体が一大プロダクトになってしまうことへの恐怖からです。。。 開発の本分は「価値を提供する、サービスを育てる」点だと思っていますので、それ以外の心労や障壁は排除しておきたいものですね!

引き続き、必要な情報を適切に摂取しながら、PHPやプログラミングを楽しんでいけたらな〜と思います!


  1. ちなみに3.xは Red Velvetです。

  2. Lastly, an explicit goal is to make the upgrade easy. と記事中で述べられています。

  3. All currently documented types will be converted into strict typehints where possible. とのこと

  4. This would make 3.6 the last 3.x with the possibility of 3.7 happening. だそうで!

  5. 全くの余談ですが、先日行われたPHPカンファレンス福岡での@hirakuさんの発表を聴いて「もっと上手くerrorを使えば開発の高速化・安心化ができるのかもなぁ」と反省したところでした。CakePHPが「phpdocだけでなくランタイムエラーを吐かせる」という課題に対してどのように取り組んで行くのかは興味深いです。
    cf: PHPのエラーと例外再入門 / php-error-and-exception // Speaker Deck

  6. 「記法がシンプルっぽいやつに」は単なる一例で、それよりも強烈に「コンセプトレベルでの変更」と言えるような機能強化が予定されていると感じています。ぜひ当該Issueの議論を眺めてみてください!

もしDHHさんがCakePHPのコントローラーを書いたら

f:id:itosho525:20170601124347p:plain

こんにちは!乃木坂46の西野七瀬さんと誕生日が同じサーバーサイドエンジニアの@itoshoです。

僕は元々PHPerなのですが、ここ1〜2年くらいRubyを書く機会が多かったこともあり、最近はRubyでいいな!と思った考え方や技術をPHPに輸入することにハマっています。

そこで今日は少し古い記事になるのですが DHHはどのようにRailsのコントローラを書くのか を参考にして、Ruby on Rails(以下Rails)の産みの親であるDHHさんのコントローラーの書き方をCakePHPに取り入れてみたいと思います。

DHHさんのコントローラーの書き方

そこに至るまでの考えなどの詳細は元記事をご覧いただければと思いますが、要約すると、

RESTの原則に従う場合、コントローラはデフォルトのCRUDアクションだけを使い、その他のアクションは新たに専用のコントローラを作成する。

という考え方になります。

DHHさん流コントローラーのメリット

基本的には以下の2つがメリットになるかと思います。

  • コントローラーがスリムになる
    • フルスタックなMVCフレームワークは往々にしてコントローラーがファットになりがちですが、デフォルトのCRUDアクションのみを利用するため、ファットコントローラーを構造的に防止することが出来ます。
  • ルーティングのルールが明確になる
    • カスタムアクションの命名規則が開発者によってバラバラになったり、そもそもそれを防止するための命名規則のガイドラインを作成したりするコストがなくなるので、ルーティングの設計コストを下げることが出来ます。

DHHさんの考えをCakePHPに適用してみる

では、早速DHHさんになりきって、CakePHPのコントローラーを書いていきましょう。 例として、元記事にもあったメールの受信箱を管理するコントローラを書いてみたいと思います。 尚、CakePHPのバージョンは3.4系を利用しており、サンプルコードのためphpDocumentorの記述などは省略しています。

コントローラークラス編

まず、デフォルトのCRUDアクションを持つコントローラークラスを書いていきます。

<?php

namespace App\Controller;

class InboxesController extends AppController
{
    public function index()
    {
        // 一覧を取得する処理
    }

    public function view($id = null)
    {
        // 詳細を取得する処理
    }

    public function add()
    {
        // 新規追加する処理
    }

    public function edit($id = null)
    {
        // 更新する処理
    }

    public function delete($id)
    {
        // 削除する処理
    }
}

Railsのデフォルトアクションは index, show, new, edit, create, update, destroy ですが、CakePHPの場合は index, view, add, edit, delete になります。

ここで新たに未送信のメール一覧が閲覧できる機能を追加しようとなった場合、よくやる実装としては、以下のようなアクションをInboxesControllerに追加するやり方ではないでしょうか。

<?php

public function pendings()
{
    // 未送信の一覧を表示する処理
}

もちろん index アクション内で出し分けるというやり方もあると思いますが、新しいアクションを追加するというアイディア自体はそれほどおかしいものではないと思います。

しかし、DHHさんはこの場合、新しいアクションではなく、以下のような新しいコントローラークラスを作成します。

<?php

namespace App\Controller\Inboxes;

use App\Controller\AppController;

class PendingsController extends AppController
{
    public function index()
    {
        // 未送信の一覧を取得する処理
    }
}

namespace App\Controller\Inboxes でサブリソースのような形で名前空間を切り、その中にコントローラークラスを作成して、デフォルトのCRUDアクションである index アクションを定義します。 ちなみに PendingsController はControllerディレクトリ内にInboxesディレクトリを作成して、その配下に格納しています。

ルーティング編

コントローラークラスが出来たので、次はルーティングの設定を行います。 今回は以下のようなREST的なルーティングが出来るようにしたいと思います。

HTTPメソッド URL 対応するコントローラアクション
GET /inboxes InboxesController::index()
GET /inboxes/123 InboxesController::view(123)
POST /inboxes InboxesController::add()
PUT(PATCH) /inboxes/123 InboxesController::edit(123)
DELETE /inboxes/123 InboxesController::delete(123)
GET /inboxes/pendings PendingsController::index()

このルーティングを実現するには routes.php 内で、

<?php

$routes->connect(
    '/inboxes',
    ['controller' => 'Inboxes', 'action' => 'index', '_method' => 'GET']
);

のようなナイーブな書き方をアクション毎に定義することでも実現出来るのですが、CakePHPでは以下のように書き方でもっとシンプルに定義することが出来ます。

<?php

$routes->resources('Inboxes');
Router::prefix('inboxes', [], function ($routes) {
    $routes->resources('Pendings');
});

このようにシンプルに書けるのもRESTに沿ったデフォルトのアクションを利用しているお陰かなと思います。

以上でDHHさん流コントローラーの完成です!

まとめ

もちろん、このやり方が全てのWebアプリケーションにとっての銀の弾丸にはなり得ませんし、RailsとCakePHPでは考え方が異なる部分もあるので、DHHさんがやっているから!という理由だけで導入するのは危険だと思います。 とは言え、少なくともRESTベースなWebAPIの開発などでは、このルールを導入するメリットはとても大きいのではないかと個人的には感じているので、これから積極的に導入していければなと考えています。

そして、PHP vs Rubyみたいな不毛な宗教戦争はやめて、今後もお互いの言語のよいところを取り入れながら、よりよいプロダクトつくっていきたいと思う次第であります。

参考サイト

jeromedalbert.com postd.cc tech.kitchhike.com qiita.com

CakePHP3.4.7にアップデートしました!

f:id:itosho525:20170430222524j:plain

こんにちは。 ℃-uteが解散してしまうのが哀しくてたまらないサーバーサイドエンジニアの@itoshoです。ちなみに℃-uteでは鈴木愛理さんが好きです。

この連載も3回目になります!今回も簡単にアップデート内容をまとめさせていただきました。

CakePHP3.4.7の変更点まとめ

今回は以下の変更がありました。

  • 非推奨メソッド用にAPIドキュメントの改善
  • メッセージがcontextと空文字の両方を持っている場合はTranslatorクラスはキー名を返却するように修正
  • ネストされたリクエストボティのパラメーターがOauth1のクライアント認証アダプターでエラーとなる不具合を修正
  • IntegrationTestCase::enableRetainFlashMessages() 関数の追加
    • assertSession()関数を利用してフラッシュメッセージをアサート出来るようです。
  • Validation::hexColor()関数の追加
  • ネストされたmatching()関数をコールするページネーションクエリが無効なSQLを発行する不具合を修正

詳細は公式のリリースノートをご覧ください。

アップデート時にやったこと

今回も軽微な変更のみだったので、composer updateコマンドを実行後、CIが通っていればOKとして、リリースを行いました。 (リリース後も特に問題は発生しておりません)

おわりに

CakePHPのアップデートが続く限り、このブログは解散しませんので、引き続きよろしくお願いいたします。

JavaScript(React+Flux)のディレクトリ構成がガタガタになりそうだったので反省して改善する

f:id:dachi023:20170524174143p:plain

こんにちは。フロントエンジニアの@ry0_adachiです。

ここのところ、React + Flux Utils *1 の構成を選択することが多く、それ以外を選択することが少なくなってきました。特に大きな不満はないし、慣れてきたので良いかもな〜と思っていたのですが、開発期間が伸びてきて、アプリ自体の規模がそこそこになってくるとFacebook公式のサンプルコードのようにシンプルな構成だけではカバーしきれない状況が生まれることもあります。運用し始めてだんだんとその辺の辛さみたいなものが見えてきたのと、継ぎ接ぎな構成になるのは嫌だったので、このタイミングで1回整理して改善してみようと思いました。

Fluxについて

Facebook提唱のアーキテクチャ、またはフレームワークです。データの流れを一方向にして、シンプルに状態管理が行えることがメリットとしてよく挙げられています。Fluxについてより詳しく知りたい方は以前書いた記事があるので良ければそちらも合わせて読んでみてください。

f:id:dachi023:20170523163305p:plain GitHub - facebook/flux: Application Architecture for Building User Interfaces

本題に入る前に

GitHubで参考になりそうなFlux Utils製のアプリケーションのディレクトリやファイルの構成を見ていると各プロジェクトに最適化されている(しようとしている)ものが多く、参考になる部分とならない部分があります。この辺はフレームワーク側で制限しない限り、それぞれが使いやすいものが生まれ続けるでしょう *2 。この記事の内容についてもハマるものもあるだろうしハマらないものもあるはずなので、こうした方が良い!というわけではなくて、あくまで参考程度に捉えてもらえると幸いです。

最初に考えた構成

最初に作り始めた時は公式のサンプルコードにあったチャットアプリをベースにして、そのあと最低限必要なものだけを足して下記の図のような構成にしました。

チャットアプリ *3 : flux/examples/flux-chat at 3.1.0 · facebook/flux · GitHub

js-root/
  ├ actions/
  │   ├ api/
  │   │   └ TodoApi.js
  │   └ TodoActions.js
  │
  ├ components/
  │   ├ TodoList.js
  │   └ TodoListItem.js
  │
  ├ constants/
  │   └ ActionTypes.js
  │
  ├ containers/
  │   └ AppContainer.js
  │
  ├ dispatcher/    
  │   └ AppDispatcher.js
  │
  ├ stores/
  │   ├ TodoStore.js
  │   └ records/
  │       └ Todo.js
  │
  └ utils/
  • 補足1. CSSは別ファイルに出力、別で読み込んでいるのでこの図では考慮しない
  • 補足2. ActionCreatorにAPIコールの責務を持たせるのでactions/api/を作成する
  • 補足3. APIクライアント以外で各レイヤーに収まらないものはutils/に集約する

この構成にして反省したこと

役割を階層で表現できていると思っていた

actions/api/が悪い例で、下記が理由です。

  1. ActionCreator以外からは呼んではいけません、を階層で表現しようとしていた
  2. 呼んではいけなさそうだな!という雰囲気を醸しているだけで呼ぼうと思えば呼べる

ガチガチにやるなら、チェックツールなどで「Action以外がAPIクライアントのメソッドをコールしているか」といった処理をするべきで、わざわざディレクトリの構造を複雑にしてまでやることではありませんでした。今は普通にコーディング規約として文字に起こしてチームメンバーに共有しておく、くらいで良いかなと思います。

Componentの中でのレイアウトとコンポーネントの切り分け

Componentの種類を「パーツを組み合わせたもの」と「パーツ」の2つではっきり分けるべきでした。参考にしていた公式のサンプルコードにはMessageSection.react.jsThreadSection.react.jsがComponentとして用意されていて、こういう風にすれば良かったのかと後から気づきました。

共通で使えるComponentなのかどうかが分からない

components/に置かれたものが「プロジェクト全体で共通的に使えるもの」なのか「特定の画面のみで使われるもの」なのかの判断をぱっと見で付けられなくなってしまったのでもう1つディレクトリを切ったほうがよかったです。

より実用的なディレクトリ構成を考える

反省点を改善できるように修正をしたのが下記の図になります。

js-root/
  ├ actions/
  │   └ TodoActions.js
  │
  ├ components/
  │   ├ common/
  │   │   ├ TextField.js
  │   │   └ Button.js
  │   └ todo/
  │       ├ Section.js
  │       ├ TodoList.js
  │       └ TodoListItem.js
  │
  ├ constants/
  │   └ ActionTypes.js
  │
  ├ containers/
  │   └ AppContainer.js
  │
  ├ dispatcher/    
  │   └ AppDispatcher.js
  │
  ├ stores/
  │   ├ TodoStore.js
  │   └ records/
  │       └ Todo.js
  │
  └ utils/
      └ api/
          └ TodoApi.js

改善されたこと

actionsの中はActionCreatorだけになった

actions/api/utils/api/にしたのでactions/にはActionCreatorだけが入ることになりました。API関連はActionCreatorから切り出されたような形になったので、例えばAPIクライアントを別パッケージにします〜となった場合でも切り出すイメージが湧きやすいかもなぁ、とそんなことも思いつきました。

ComponentにSectionを設ける

Sectionを設けたことでレイアウトやパーツの集合体を定義するクラスが明確になり迷うことがなくなりました。Sectionがレイアウトやパーツの集合体でそれ以外はただのパーツである、という認識をしっかり持てたことで前に比べるとチーム開発もしやすくなったかもしれません(今は私1人でJS書いてるのでまだ試してませんが…)。

共通なComponentとそうでないものはディレクトリを分ける

プロジェクト内で使い回しの効くComponentを切り出したことで「前にこんなの作ったけ?」と考える時間が減ったのと、共通化しようという意図が見えやすくなりました。この辺はUIを考えてくれているデザイナーさんに相談しながら少しずつ共通化して切り出していくようにしています。

余談ですが、Componentが共通化される条件は「ロジック的に使い回せるか?」よりも「UIとして使い回せるか?」を判断軸にしています。これは、CSSとComponentの組み方の乖離 *4 が大きくなると実装が後々大変になるだろう、と判断してそうしています。

まとめ

事前に想定できるケースを洗い出しておくのは前提として、最初に決めた構成のまま突き進むのではなく状況に合わせて適宜変更していく・変更しやすい状態を保つことが重要です。また、途中で開発チームの規模が大きくなるかもしれないので複数人でも開発しやすい状態などを考慮しておくことも重要です。開発者が考える時間を減らしてあげることは開発効率の向上にも繋がるのでしっかりとメンテナンスしていきたいですね。

脚注

*1:Flux UtilsはFluxのリポジトリ(facebook/flux)に含まれています。

*2:現状は決定版となる構成が特にない状況だと認識しています。

*3:2017/05/25: masterにはなかったので3.1.0のタグから引っ張ってきています。

*4:CSSは共通化しているのにComponentはされていない、といったズレが生じている状態。

CakePHP3.4.6にアップデートしました!

f:id:itosho525:20170430222524j:plain

こんにちは。 GWはずっと欅坂46の『不協和音』を聴いていたサーバーサイドエンジニアの@itoshoです。 前回のエントリーからCakePHP3アップデートの連載?を担当しています。

そして、早速GW中に新しいバージョンである3.4.6がリリースされましたので、今回も簡単にではありますがアップデート内容をまとめさせていただきました。

CakePHP3.4.6の変更点まとめ

今回は以下の変更がありました。

  • CSRFとセキュリティトークン用のフィールドのautocomplete属性を明示的に無効にした
    • 新しいSafariのバックボタンの挙動で、blackholedエラーが発生する問題を解決しています。
  • SQLServerの接続ドライバーに多数のオプションが追加
    • 具体的にはコネクションプーリングやログインタイムアウト等のオプションが追加されました
  • APIドキュメントの改善
  • FixtureのDB接続のコネクションが常に別名を使うように修正
    • これによりテスト時に利用するDBが定義されていない時に、誤って生(≒本番)データに接続する危険が回避されます。
  • 翻訳パッケージ(Aura.Intl)が、Cake3.3で生成されたキャッシュファイルからinitializeする時に発生していた不具合を修正。
  • and*()メソッド及びor*()メソッドに追加される条件句(conditions)をいずれも後ろに追加するように修正
    • 以前は and*()メソッドは条件句を後ろに追加、or*()メソッドは条件句を前に追加(prepend)していました。
    • 生成されるSQL文としては順番が逆でも影響はありませんが、混乱するので統一したようです。

詳細は公式のリリースノートをご覧ください。

また、リリースノートには記載されていませんが、GitHubのREADMEにCakeのロゴが追加されたようです!

アップデート時にやったこと

3.4.5へのアップデート同様、今回も軽微な変更のみだったので、composer updateコマンドを実行後、CIが通っていればOKとして、リリースを行いました。

おわりに

日々開発しているシステムに不協和音が起きないようにフレームワークのアップデートは早め早めに実施していきましょう。(自戒も込めて)