Problèmes ORM non bloquants

J'ai posé une question sur SO, et j'ai constaté qu'il n'y a pas d'ORM non bloquant pour mon framework web préféré. Par non-blocage, j'entends un ORM avec prise en charge de rappel pour la récupération asynchrone. L'ORM serait fourni avec un rappel ou quelque chose du genre à exécuter lorsque des données auront été reçues.

Je veux en créer un, mais j'ai quelques questions qui m'empêchent de commencer le développement:

• Quels problèmes pourraient être rencontrés lors du développement de l'ORM?
• La prise en charge de la récupération non bloquante augmente-t-elle considérablement la complexité d'un ORM?
• Pourquoi y a-t-il si peu d'ORM non bloquants?

Mise à jour: il semble que je doive améliorer ma question. Nous avons des solutions qui nous permettent déjà de recevoir des données de manière non bloquante, et je pense que la plupart des entreprises qui utilisent de telles solutions utilisent du SQL brut. Nous voulons créer une solution plus générique que nous pourrons réutiliser dans de futurs projets. Quelles difficultés pourrions-nous rencontrer?

Mise à jour 2: le langage préféré est le python, mais je m'intéresse aux principes. Cette question est en fait pour moi, car je vais regarder les plates-formes qui ont déjà un ORM non bloquant.

Quels problèmes pourraient être rencontrés lors du développement de l'ORM?

Vous devrez résoudre la liste des problèmes requis pour combler le décalage entre l'impédance relationnelle des objets et traiter les particularités de SQL fournies par chaque fournisseur de SGBDR. Plus vos exigences sont avancées, plus vos problèmes s'aggraveront dans ce service: par exemple, SQL que vous générez pour implémenter la pagination des résultats différera de manière assez spectaculaire entre Oracle, SQL Server et mysql. Heureusement, cela n'est pas différent entre les implémentations ORM bloquantes et non bloquantes, donc s'il existe un ORM open source pour Python, vous seriez en mesure d'emprunter massivement pour résoudre presque tous ces problèmes.

La prise en charge de la récupération non bloquante augmente-t-elle considérablement la complexité d'un ORM?

Le plus gros problème auquel vous allez faire face est que la bibliothèque de connexion pour accéder au SGBDR lui-même serait bloquée. C'est une autre différence que vous devez aborder. Gérer les fils invisibles pour vos utilisateurs sera le défi supplémentaire pour vous. De plus, le chargement des dépendances à la demande serait un défi, car l'opération est perçue comme synchrone par les utilisateurs de votre framework: après tout, ils n'attendent normalement pas de notification quand il est autorisé d'accéder à une propriété de collection de leur objet.

Pourquoi y a-t-il si peu d'ORM non bloquants?

Je ne peux que spéculer sur ce dernier point, mais je pense que cela a à voir avec la faible demande pour de tels frameworks: puisque vous pouvez simuler partiellement ORM non bloquant en ajoutant un autre niveau de threading à votre code d'application si nécessaire, et garder le blocage régulier genre partout ailleurs, développer un cadre spécialisé pour cela semblerait sous-optimal.

Vous n'avez pas dit quelle langue vous utilisez, donc je vais recommander Node.js, et un ORM pour cela: Node ORM , tout dans le nœud est asynchrone, ce n'est pas différent.