Неблокуючі проблеми ORM

Я поставив запитання щодо SO і виявив, що для моєї улюбленої веб-рамки не існує блокуючих ORM. Під неблокуванням я маю на увазі ORM з підтримкою зворотного дзвінка для асинхронного пошуку. ORM буде постачатися з зворотним дзвінком або іншим таким чином, щоб виконати, коли дані отримані.

Я хочу створити його, але у мене є деякі питання, які заважають мені почати розробку:

• Які проблеми можуть виникнути при розробці ORM?
• Чи підтримує пошук, що не блокує, різко збільшує складність ОРМ?
• Чому навколо так мало неблокуючих ORM?

Оновлення: Схоже, я маю вдосконалити своє питання. У нас є рішення, які вже дозволяють нам отримувати дані не блокуючим способом, і я вважаю, що більшість компаній, які використовують такі рішення, використовують необроблений SQL. Ми хочемо створити більш загальне рішення, яке ми можемо використовувати повторно у майбутніх проектах. З якими труднощами ми можемо зіткнутися?

Оновлення 2: Краща мова - це python, але мене цікавлять принципи. Це питання насправді для мене, оскільки я буду дивитись на платформи, які вже не блокують ORM.

Які проблеми можуть виникнути при розробці ORM?

Вам потрібно буде вирішити список проблем, необхідних для усунення невідповідності об'єктного реляційного імпедансу , а також розгляду ідіосинкрасій SQL, наданих кожним постачальником RDBMS. Чим досконаліші ваші вимоги, тим гірші ваші проблеми будуть у цьому відділі: наприклад, SQL, який ви створюєте для впровадження пейджингу результатів, буде досить різко відрізнятися між Oracle, SQL Server та mysql. На щастя, це не відрізняється між блокуючими та неблокуючими реалізаціями ORM, тому, якщо існує ORM з відкритим кодом для Python, ви зможете сильно запозичити його для вирішення майже всіх цих проблем.

Чи підтримує пошук, що не блокує, різко збільшує складність ОРМ?

Найбільшою проблемою, з якою ви стикаєтеся, є те, що бібліотека з'єднань для доступу до RDBMS сама буде блокована. Це ще одна відмінність, яку ви повинні вирішити. Управління нитками, невидимими для ваших користувачів, стане для вас додатковим викликом. Крім того, завантаження залежностей від попиту було б складним завданням, оскільки операція сприймається як синхронна користувачами вашої фреймворку: адже вони зазвичай не очікують сповіщення про те, коли це нормально, щоб отримати доступ до власності колекції свого об'єкта.

Чому навколо так мало неблокуючих ORM?

Я можу лише спекулювати на цьому останньому моменті, але я думаю, що це стосується низького попиту на такі рамки: оскільки ви можете частково імітувати неблокуючий ORM, додавши інший рівень введення в ваш код програми за потребою, і тримати регулярне блокування будь-де скрізь, розробка спеціалізованих рамок для цього здавалася б неоптимальною.

Ви не сказали, якою мовою користуєтесь, тож я порекомендую Node.js та ORM для цього: Node ORM , все у вузлі асинхронне, це не відрізняється.