ReactiveCrudRepository pour utiliser Hibernate au printemps
Est-il possible d'utiliser Hibernate et Mysql avec ReactiveCrudRepository au lieu de CrudRepository? J'ai essayé des échantillons avec Spring Data Jpa et Hibernate, mais je n'ai pas réussi à le faire fonctionner. Je n'ai pu trouver que quelques échantillons sur ReactiveCrudRepository pour MongoDB et cassandra .
Est-il possible d'utiliser Hibernate et Mysql avec
ReactiveCrudRepositoryau lieu deCrudRepository?
TL; DR:
Pas avec Hibernate et MySQL, mais avec R2DBC et Postgres, Microsoft SQL Server ou H2 . Regardez Spring Data R2DBC .
Version longue
Pourquoi pas JPA?
Si Hibernate/JPA est inclus, cela ne se produira pas dans un avenir prévisible… .. JPA est basé sur l'idée que vous chargez une partie de votre modèle de données en mémoire, manipulez le modèle objet résultant et laissez JPA transformer ces modifications . Tout cela en une seule transaction.
C’est un peu l’opposé de la manière dont on traite avec un magasin réactif dans lequel on essaie d’apporter des modifications atomiques et de découpler le chargement, le traitement et le stockage et tout cela sans bloquer.
Pourquoi pas JDBC?
Nous devons donc examiner le niveau de technologie inférieur à JPA: JDBC . Mais JDBC continue de bloquer: vous envoyez une instruction SQL à votre base de données, puis JDBC bloquera jusqu’à ce que vous obteniez le résultat. Et là encore, cela va à l’encontre de l’idée de réactif: ne jamais bloquer. On pourrait envelopper cela dans un pool de threads pour atténuer cela dans une certaine mesure, mais c'est plus une solution de contournement qu'une solution.
Pourquoi R2DBC?
Il existe des pilotes appropriés pour certaines bases de données qui pourraient être utilisés pour les référentiels réactifs. Mais ils sont propriétaires et ne constituent donc pas une bonne base pour quelque chose qui devrait vraiment fonctionner à terme dans toutes les bases de données relationnelles (pertinentes).
Pendant un certain temps, l'équipe Spring Data espérait que ADBA comblerait cette lacune… .. Mais les discussions sur la liste de diffusion ont clairement montré que ADBA ne visait pas la réactivité, mais uniquement l'asynchrone…. Encore une fois pas ce dont nous avions besoin pour une abstraction réactive de référentiel.
Ainsi, au début de 2018, diverses personnes vivant à l'intersection ou réactives et relationnelles ont décidé que nous avions besoin d'une norme pour l'accès réactif aux bases de données.
R2DBC (R eactive R elational D atabase A ccess) Est une proposition en ce sens. standard . On espère que cela aidera à convaincre Oracle de passer ADBA à une approche réactive ou si cela ne se produit pas, cela deviendra le standard lui-même.
Et avec déjà trois implémentations, les chances de la deuxième option semblent prometteuses.
R2DBC lui-même est principalement un SPI, c’est-à-dire une API qui doit être implémentée par les fournisseurs de base de données . Le SPI est conçu de manière à imposer un minimum d’exigences aux implémenteurs. Mais cela rend aussi R2DBC un peu lourd à utiliser. L’idée est que d’autres bibliothèques s’intensifieront et construiront des bibliothèques conçues pour être utilisables au-dessus de ce SPI, comme ce fut le cas avec JDBC.
Données de printemps R2DBC
Spring Data R2DBC est l’une de ces bibliothèques et offre ce que vous avez demandé: Prise en charge de ReactiveCrudRepository bien qu’elle soit indépendante de JPA/Hibernate et qu’il n’existe pas encore de prise en charge de MySQL.
Etat des projets
R2DBC et Spring Data R2DBC n'avaient pas encore de version de production et il faudrait au moins plusieurs mois pour y parvenir.
Spring Data R2DBC vient de publier le premier jalon. Voir l’article concernant les fonctionnalités actuelles } _.
R2DBC est à sa 6ème étape. Voir le article de version pour plus de détails }.
Voir aussi cette réponse: Pourquoi Spring ne fournit-il pas de clients réactifs (non bloquants) pour les bases de données relationnelles?
Réponse originale comme référence pour les archéologues:
Pour l'instant (janvier 2017), ce n'est pas possible.
La version actuellement pertinente pour la partie réactive de Spring Data est la suivante: Spring Data Kay M1 _ (vous pouvez vérifier si une version plus récente est disponible sur la page d'accueil du projet ).
Et un article de blog de l'équipe de Spring Data sur cette version et plus particulièrement sur les parties réactives de celle-ci commence par (souligné par moi):
Spring Data Kay M1 est la toute première version du marché à prendre en charge l’accès réactif aux données. Son ensemble initial de magasins pris en charge - MongoDB, Apache Cassandra et Redis - sont déjà livrés avec des pilotes réactifs, ce qui en faisait des candidats tout à fait naturels pour un tel prototype.
La raison en est qu’il n’existe pas de moyen standard non bloquant d’accéder à une base de données relationnelle. Ainsi, seuls ceux qui prennent en charge ce type d’API sont actuellement pris en charge.
On pourrait implémenter une ReactiveCrudRepository en utilisant JPA ou JDBC et déléguer le travail à un pool de threads. Cela fournirait une API asynchrone à l'extérieur, mais consommerait tout de même les ressources pour les Threads et le blocage entre les accès indépendants aux données, de sorte que seule une petite partie des avantages de l'approche réactive serait réalisée.
Selon la citation de la réponse précédente
On pourrait implémenter un ReactiveCrudRepository en utilisant JPA ou JDBC et en déléguant le travail à un pool de threads. Cela fournirait une API asynchrone à l'extérieur, mais consommerait tout de même les ressources pour les Threads et le blocage entre les accès indépendants aux données, de sorte que seule une petite partie des avantages de l'approche réactive serait réalisée.
James Ward affirme que cela peut être non bloquant. Je veux dire je lui ai demandé:
oui ok, mais ScalikeJDBC-Async ne fait-il pas exactement la même chose? mettre juste l'invocation de requête dans un autre pool de threads?
et il a répondu
Non, car ScalalikeJDBC-Async utilise https://github.com/mauricio ... qui est en fait un pilote de base de données JDBCish non bloquant (NIO).
Ainsi, vous pouvez être réactif en remplaçant les données hibernate + spring par postgresql-async (devrait fonctionner avec mysql).