L'outillage est peu normalisé, je te l'accorde. Mais ce n'est pas trop compliqué non plus à mettre en oeuvre. Etant proche des données, c'est assez naturel de tester unitairement les différentes phases d'un traitement complexe. Je suis moyennement convaincu par l'argument.
Je suis intéressé pour avoir des pointeurs sur ce genre de choses. Comment on teste unitairement ce code ? Comment le mettre en place dans une intégration continue ?
Le langage PL/pgSQL de PostgreSQL possède une gestion des exceptions ainsi qu'un système de diagnostique (une sorte de stack trace). Il est aussi possible d'utiliser d'autres langages (non spécialisés à la base de données) avec leur avantages et inconvénients.
Ton erreur doit passer du sgbdr à l'applicatif pour être remontée dans l'UI. Avoir déjà une conversion ce n'est pas toujours très bien fais alors en avoir 2...
Ce n'est pas non plus d'une facilité enfantine à traiter côté applicatif.
Ça dépend évidemment de ce que tu fais, mais il est possible d'avoir des services sans état ce qui n'a pas de sens d'un point dans un moteur de base de données. Tu peux trouver un paquet d'architectures pour ce genre de choses. Elles ne cherchent pas à minimiser la place de la base de données, mais donne à chaque élément une responsabilité plus simple et totalement dans son domaine. Tu peux voir l'architecture lambda, la stack SMACK,...
Après oui avec de petits projets (quand les index voir les données elles même tiennent en mémoire) tout marche, mais tu n'a alors aucune contraintes. N'importe quel moteur de données fonctionne et tu peux traiter la donnée où tu veux sans véritable problème.
[^] # Re: Utilisation
Posté par barmic 🦦 . En réponse au journal Sortie de "The Art of PostgreSQL" de Dimitri Fontaine. Évalué à 1.
Je suis intéressé pour avoir des pointeurs sur ce genre de choses. Comment on teste unitairement ce code ? Comment le mettre en place dans une intégration continue ?
Ton erreur doit passer du sgbdr à l'applicatif pour être remontée dans l'UI. Avoir déjà une conversion ce n'est pas toujours très bien fais alors en avoir 2...
Ça dépend évidemment de ce que tu fais, mais il est possible d'avoir des services sans état ce qui n'a pas de sens d'un point dans un moteur de base de données. Tu peux trouver un paquet d'architectures pour ce genre de choses. Elles ne cherchent pas à minimiser la place de la base de données, mais donne à chaque élément une responsabilité plus simple et totalement dans son domaine. Tu peux voir l'architecture lambda, la stack SMACK,...
Après oui avec de petits projets (quand les index voir les données elles même tiennent en mémoire) tout marche, mais tu n'a alors aucune contraintes. N'importe quel moteur de données fonctionne et tu peux traiter la donnée où tu veux sans véritable problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll