Problemas de ORM sin bloqueo

Hice una pregunta sobre SO y descubrí que no hay ORM sin bloqueo para mi marco web favorito. Por no bloqueo me refiero a un ORM con soporte de devolución de llamada para recuperación asincrónica. El ORM recibiría una devolución de llamada o algo similar para ejecutar cuando se hayan recibido los datos.

Quiero crear uno, pero tengo algunas preguntas que me impiden comenzar el desarrollo:

• ¿Qué problemas pueden surgir al desarrollar ORM?
• ¿Apoyar la recuperación sin bloqueo aumenta dramáticamente la complejidad de un ORM?
• ¿Por qué hay tan pocos ORM sin bloqueo?

Actualización: Parece que tengo que mejorar mi pregunta. Tenemos soluciones que ya nos permiten recibir datos de manera no bloqueante, y creo que la mayoría de las empresas que usan tales soluciones usan SQL sin formato. Queremos crear una solución más genérica que podamos reutilizar en futuros proyectos. ¿Qué dificultades podríamos encontrar?

Actualización 2: El lenguaje preferido es python, pero estoy interesado en los principios. Esta pregunta es para mí, ya que veré las plataformas que ya tienen ORM sin bloqueo.

¿Qué problemas pueden surgir al desarrollar ORM?

Tendrá que abordar la lista de problemas necesarios para cerrar la No coincidencia de impedancia relacional de objetos , así como tratar con las idiosincrasias de SQL proporcionadas por cada proveedor de RDBMS. Cuanto más avanzados sean sus requisitos, mayores serán sus problemas en este departamento: por ejemplo, el SQL que genere para implementar la paginación de resultados diferirá dramáticamente entre Oracle, SQL Server y mysql. Afortunadamente, esto no es diferente entre las implementaciones de ORM bloqueadoras y no bloqueadoras, por lo que si hay un ORM de código abierto para Python, podría pedirlo prestado para abordar casi todos estos problemas.

¿Apoyar la recuperación sin bloqueo aumenta dramáticamente la complejidad de un ORM?

El mayor problema al que se enfrentará es que la biblioteca de conexión para acceder al RDBMS estaría bloqueándose. Esta es otra diferencia que debe abordar. Administrar los hilos invisibles para sus usuarios será el desafío adicional para usted. Además, la carga de dependencias a pedido sería un desafío, porque los usuarios de su marco perciben la operación como sincrónica: después de todo, normalmente no esperan una notificación sobre cuándo está bien acceder a una propiedad de colección de su objeto.

¿Por qué hay tan pocos ORM sin bloqueo?

Solo puedo especular sobre este último punto, pero creo que tiene que ver con la baja demanda de dichos marcos: ya que puede simular parcialmente ORM sin bloqueo agregando otro nivel de subprocesamiento al código de su aplicación según sea necesario, y mantener el bloqueo regular como en cualquier otro lugar, desarrollar un marco especializado para él parecería subóptimo

No dijo qué idioma está utilizando, así que le recomendaré Node.js y un ORM para ello: Node ORM , todo en el nodo es asíncrono, esto no es diferente.