ノンブロッキングORMの問題

私はSO について質問しましたが、私のお気に入りのWebフレームワークにはノンブロッキングORMがないことがわかりました。非ブロッキングとは、非同期検索のためのコールバックをサポートするORMを意味します。ORMには、データが受信されたときに実行されるコールバックなどが提供されます。

作成したいのですが、開発の開始を妨げるいくつかの質問があります。

• ORMの開発時に発生する可能性のある問題は何ですか？
• ノンブロッキング検索をサポートすると、ORMの複雑さが劇的に増加しますか？
• なぜ非ブロッキングORMが非常に少ないのですか？

更新：質問を改善する必要があるようです。私たちはすでに非ブロッキングの方法でデータを受け取ることができるソリューションを持っています、そして私はそのようなソリューションを使用するほとんどの会社が生のSQLを使用すると信じています。今後のプロジェクトで再利用できる、より一般的なソリューションを作成したいと考えています。私たちはどんな困難に遭遇するでしょうか？

更新2：優先言語はpythonですが、私は原則に興味があります。この質問は実際に私のためです。私はすでにノンブロッキングORMを持っているプラ​​ットフォームを見ていきます。

ORMの開発時に発生する可能性のある問題は何ですか？

Object Relational Impedance Mismatchを埋めるために必要な問題のリストを整理し、各RDBMSベンダーが提供するSQLの特異性に対処する必要があります。要件が高度になるほど、この部門のトラブルは悪化します。たとえば、結果ページングを実装するために生成するSQLは、Oracle、SQL Server、およびmysqlの間でかなり劇的に異なります。幸いなことに、これはブロッキングORM実装と非ブロッキングORM実装の間で違いはないので、Python用のオープンソースORMがあれば、そこから大いに借りてこれらすべての問題に対処することができます。

ノンブロッキング検索をサポートすると、ORMの複雑さが劇的に増加しますか？

直面する最大の問題は、RDBMS自体にアクセスするための接続ライブラリがブロックすることです。これは、対処しなければならないもう1つの違いです。ユーザーから見えないスレッドを管理することは、あなたにとってさらなる課題です。さらに、フレームワークのユーザーは操作を同期していると認識しているため、依存関係をオンデマンドでロードすることは困難です。結局のところ、通常、オブジェクトのコレクションプロパティにアクセスしてもよいという通知を期待していません。

なぜ非ブロッキングORMが非常に少ないのですか？

私はこの最後の点について推測することしかできませんが、それはそのようなフレームワークの需要が低いことと関係があると思います：必要に応じてアプリケーションコードに別のレベルのスレッドを追加することで非ブロッキングORMを部分的にシミュレートし、通常のブロッキングを維持できるため他の場所では親切であり、そのための特殊なフレームワークを開発するのは最適ではないようです。

：あなたは、私がNode.jsのをお勧めするつもりですので、使用している、そしてそれのためのORMどの言語も言わなかったノードのORMは、ノード内のすべてが、これは違いはありません、非同期です。