tests sur plusieurs fournisseurs SGBD

Question

Prenez cette requête:

SELECT * 
    FROM MyTable 
    WHERE MyColumn = 'SomeValue' 
ORDER BY SomeFakeQualifier.MyColumn DESC 

Il semble que SqlServer ignore simplement le qualificatif dans ce cas. Si vous ajoutez un JOIN, il le considérera.

Ce n'est vraiment pas un problème, jusqu'à ce que vous souhaitiez rendre vos requêtes viables à travers les fournisseurs de SGBD. Oracle, par exemple, se plaindra, à juste titre, que le qualificatif est invalide. Oui, nous utilisons un ORM qui élimine beaucoup de cela, mais nous avons encore besoin de JDBC pour certaines actions (c'est la nature de notre produit et son support pour les requêtes dynamiques). En fait, c'est à cause de cela que ce problème est survenu - quelqu'un a copié une requête JPA nommée à une requête fournie par JDBC, mais laissé dans le nom de l'objet au lieu du nom de la table. Donc je suppose que la question est: est-ce que quelqu'un d'autre est tombé sur cela? Si oui, quelle est la meilleure façon de tester votre code pour vous assurer qu'il fonctionnera dans les trois principaux SGBD (SqlServer, Oracle, DB2)? Nous avons une équipe d'assurance qualité, mais il semble qu'il devrait y avoir une meilleure façon de tester unitaire pour ces idiosyncrasies.

Note, nous essayons toujours de faire respecter l'écriture de la norme ANSI SQL pour éviter les problèmes, mais certaines choses, comme la question ci-dessus, peut passer à travers

J'espère que cela a du sens. Je peux fournir plus de contexte si nécessaire.

TIA

Answer 1

Votre solution ici est vraiment des tests unitaires de vos requêtes combinées avec continuous integration. Vous avez des requêtes sous la forme de code JDBC. Il est assez facile d'écrire des tests unitaires pour se connecter à vos bases de données pertinentes et exécuter les requêtes de telle manière que vous puissiez au moins voir si elles s'exécutent, même si vous ne vous souciez pas des résultats, ce qui est la norme dont vous parlez . Vous pouvez sans doute prolonger cela pour mesurer la performance et/ou les résultats, mais je trouve que ces sortes de tests sont extrêmement fragiles et ont tendance à se casser très, très rapidement, car plus de changements se produisent inévitablement.