Problemi di ORM non bloccanti

Ho fatto una domanda su SO e ho scoperto che non ci sono ORM non bloccanti per il mio framework Web preferito. Per non-blocco intendo un ORM con supporto di callback per il recupero asincrono. L'ORM verrebbe fornito con un callback o qualcosa del genere da eseguire quando i dati sono stati ricevuti.

Voglio crearne uno, ma ho alcune domande che mi impediscono di iniziare lo sviluppo:

• Quali problemi potrebbero verificarsi durante lo sviluppo di ORM?
• Il supporto del recupero non bloccante aumenta notevolmente la complessità di un ORM?
• Perché ci sono così pochi ORM non bloccanti in giro?

Aggiornamento: sembra che debba migliorare la mia domanda. Disponiamo di soluzioni che ci consentono già di ricevere dati in modo non bloccante e credo che la maggior parte delle aziende che utilizzano tali soluzioni utilizzino SQL non elaborato. Vogliamo creare una soluzione più generica che possiamo riutilizzare in progetti futuri. Quali difficoltà potremmo incontrare?

Aggiornamento 2: la lingua preferita è Python, ma sono interessato ai principi. Questa domanda è in realtà per me, poiché esaminerò piattaforme che dispongono già di ORM senza blocco.

Quali problemi potrebbero verificarsi durante lo sviluppo di ORM?

Dovrai affrontare l'elenco completo dei problemi richiesti per colmare la mancata corrispondenza di impedenza relazionale degli oggetti , oltre a gestire le idiosincrasie di SQL fornite da ciascun fornitore RDBMS. Quanto più avanzate sono le tue esigenze, tanto maggiori saranno i tuoi problemi in questo reparto: ad esempio, l'SQL generato per implementare il paging dei risultati differirà in modo piuttosto drammatico tra Oracle, SQL Server e mysql. Fortunatamente, questo non è diverso tra le implementazioni ORM bloccanti e non bloccanti, quindi se esiste un ORM open source per Python, si sarebbe in grado di prendere in prestito pesantemente da esso per affrontare quasi tutti questi problemi.

Il supporto del recupero non bloccante aumenta notevolmente la complessità di un ORM?

Il problema più grande che dovrai affrontare è il blocco della libreria di connessione per l'accesso al RDBMS stesso. Questa è un'altra differenza che devi affrontare. La gestione delle discussioni invisibili per i tuoi utenti sarà la sfida aggiuntiva per te. Inoltre, il caricamento di dipendenze su richiesta sarebbe una sfida, poiché l'operazione è percepita come sincrona dagli utenti del framework: dopo tutto, normalmente non si aspettano una notifica quando è OK per accedere a una proprietà di raccolta del loro oggetto.

Perché ci sono così pochi ORM non bloccanti in giro?

Posso solo speculare su quest'ultimo punto, ma penso che abbia a che fare con una bassa richiesta di tali framework: poiché puoi parzialmente simulare ORM non bloccante aggiungendo un altro livello di threading al codice dell'applicazione, se necessario, e mantenere il blocco regolare gentile ovunque, lo sviluppo di un quadro specializzato per esso sembrerebbe non ottimale.

Non hai detto quale lingua stai usando, quindi consiglierò Node.js e un ORM per questo: Nodo ORM , tutto nel nodo è asincrono, questo non è diverso.