今日、
PHPixieのデータベースアクセスモジュールのバージョン3.0の最新のテストを
作成しました 。 始めたときは数週間しかかからなかったように見えましたが、実際には、最初は膨大な量のリファクタリングと書き直しのために約2か月続きました。 しかし、現在では、フレームワーク自体の外部でも使用できる拡張可能なライブラリがあります（つまり、他のフレームワークまたはCMSでの書き込みを強制される場合は、お気に入りのライブラリを持ち歩くことができます）。
ORMモジュールを完成させ、新しいAPIで動作するように既存のモジュールを調整した後、リリースします。 ただし、興味がある場合は
、githubの3.0ブランチを調べることができます（ただし、ドキュメントがまだないことを警告する必要があります
。ORMとともに表示されます）。 それでは、新機能を見てみましょう。
平均的なユーザーの観点から
MongoDBの論理条件を使用した高度なクエリのサポートについては、すでにここに書いていますが、このリンクをクリックするのが面倒な場合は、簡単な説明を以下に示します。MongoDBでは、「
）） 」、したがって、PHPixie自体が、要求を使用するような形式で要求をリードします。
クエリを構築するためのいくつかのアプローチが利用可能になりました。
$query ->where('name', 'Trixie') ->or_where('name', 'Tinkerbell') ->where_not('id', '>', 7) ->having('count','<', 5) ->or_having('count', 7);
ネストされたロジックへのいくつかのアプローチ：
$query ->where('name','Trixie') ->_or(function($builder){ $builder ->_and('id',7) ->_or('id',5) });
列を比較するための特別な演算子：
$query->where('fairies.id','*=','pixies.id');
個別のパラメーターでSQLコード挿入を使用する機能：
$expr = $this->db->expr('concat(name, ?)', array('test')); $query->where($expr, 'Trixietest');
NULLであることを事前に知らずに、NULL値で文字列を検索します。
$category_id = null; $query->where('category_id', $category_id);
JOINの難しい条件....おなじみの構文を使用してON：
$query->join('pixies');
上級開発者の観点から
- 信じられないほど軽量、わずか57キロバイトのコード
- クエリビルダーには、解析に関連するロジックは含まれていません（たとえば、SQLコード内）。 代わりに、各ドライバーは独自のパーサーサービスを使用して、クエリオブジェクト自体をメモリの観点から軽量で安価にします。 パーサーをサービスとして使用すると、デバッグと拡張が簡単なタスクになります。 ちなみに、各パーサーはすべてのリクエストに対して一度だけメモリに作成されます。
- 各パーサーは、個々の条件および条件グループのパーサーに分割されます（条件グループパーサー）。 この分離により、カスタム演算子を簡単に追加できます。
- 依存関係のバインドは個別のドライバークラスで実行されます。つまり、例外をスローする場合を除いて、 新しいコマンドを使用してそれ自体でオブジェクトを作成するクラスはありません。 これにより、クラスをその実装に簡単に置き換えることができます。
- MongoDBへのリクエストは、エラーが発生した場合にデバッグしやすい特別なRunnerオブジェクトに解析されます。
- PDOを介して動作するSQLデータベースには、独自のアダプターとパーサーがあり、最小限のコードでPDOが動作するデータベースのサポートを簡単に追加できます。
コードはPHPUnitテストで完全にカバーされており、166個のテストと1151個の比較が可能です。この投稿が完了した作業に私の喜びを伝え、ORMモジュールの最終リリースが遠くないことを願っています。