Problemas de ORM sem bloqueio

Fiz uma pergunta no SO e descobri que não existem ORMs sem bloqueio para minha estrutura da web favorita. Por não-bloqueio, refiro-me a um ORM com suporte a retorno de chamada para recuperação assíncrona. O ORM seria fornecido com um retorno de chamada ou algo parecido para executar quando os dados fossem recebidos.

Quero criar uma, mas tenho algumas perguntas que me impedem de iniciar o desenvolvimento:

• Quais problemas podem ser encontrados ao desenvolver o ORM?
• O suporte à recuperação sem bloqueio aumenta drasticamente a complexidade de um ORM?
• Por que existem tão poucos ORMs sem bloqueio por aí?

Atualização: parece que tenho que melhorar minha pergunta. Temos soluções que já nos permitem receber dados de maneira não-bloqueadora e acredito que a maioria das empresas que usam essas soluções utiliza SQL bruto. Queremos criar uma solução mais genérica que possamos reutilizar em projetos futuros. Que dificuldades podemos encontrar?

Atualização 2: o idioma preferido é o python, mas estou interessado em princípios. Esta pergunta é realmente para mim, pois examinarei as plataformas que já possuem ORM sem bloqueio.

Quais problemas podem ser encontrados ao desenvolver o ORM?

Você precisará abordar a lista completa de problemas necessários para preencher a incompatibilidade de impedância relacional do objeto , além de lidar com as idiossincrasias do SQL fornecidas por cada fornecedor do RDBMS. Quanto mais avançados forem seus requisitos, piores serão seus problemas neste departamento: por exemplo, o SQL que você gerar para implementar a paginação de resultados diferirá bastante drasticamente entre Oracle, SQL Server e mysql. Felizmente, isso não é diferente entre as implementações de ORM de bloqueio e de não bloqueio; portanto, se houver um ORM de código aberto para Python, você poderá emprestá-lo fortemente para resolver quase todos esses problemas.

O suporte à recuperação sem bloqueio aumenta drasticamente a complexidade de um ORM?

O maior problema que você enfrentará é que a biblioteca de conexões para acessar o próprio RDBMS estaria bloqueando. Essa é outra diferença que você deve abordar. Gerenciar os threads invisíveis para seus usuários será o desafio adicional para você. Além disso, o carregamento de dependências sob demanda seria um desafio, porque a operação é percebida como síncrona pelos usuários de sua estrutura: afinal, eles normalmente não esperam uma notificação sobre quando está certo acessar uma propriedade de coleção de seu objeto.

Por que existem tão poucos ORMs sem bloqueio por aí?

Só posso especular sobre esse último ponto, mas acho que tem a ver com a baixa demanda por essas estruturas: como você pode simular parcialmente o ORM sem bloqueio adicionando outro nível de encadeamento ao código do aplicativo, conforme necessário, e manter o bloqueio regular em qualquer outro lugar, o desenvolvimento de uma estrutura especializada para ela pareceria não ideal.

Você não disse qual idioma está usando, então eu recomendarei o Node.js e um ORM para ele: Nó ORM , tudo no nó é assíncrono, isso não é diferente.