Тестирование нескольких поставщиков СУБД - PullRequest
1 голос
/ 10 мая 2009

Возьмите этот запрос:

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

Похоже, что SqlServer просто игнорирует классификатор в этом случае. Если вы добавите JOIN, то он его рассмотрит.

Это действительно не проблема, пока вы не захотите сделать ваши запросы жизнеспособными среди поставщиков СУБД. Например, Oracle по праву будет жаловаться на то, что квалификатор недействителен.

Да, мы используем ORM, который устраняет многое из этого, но нам все еще нужен JDBC для некоторых действий (это характер нашего продукта и его поддержка динамических запросов). Фактически, именно из-за этой возникла эта проблема: кто-то скопировал именованный запрос JPA в запрос, предоставленный JDBC, но оставил его в имени объекта вместо имени таблицы.

Итак, я предполагаю, что вопрос: кто-нибудь еще сталкивался с этим? Если да, то как лучше всего протестировать ваш код, чтобы убедиться, что он будет работать в «трех основных» СУБД (SqlServer, Oracle, DB2)? У нас есть команда QA, но, похоже, должен быть лучший способ модульного тестирования для этих идиосинкразий.

Обратите внимание, что мы всегда стараемся принудительно писать ANSI SQL, чтобы избежать проблем, но некоторые вещи, такие как вышеупомянутая проблема, могут ускользнуть через

Надеюсь, это имеет смысл. Я могу предоставить больше контекста, если это необходимо.

ТИА

1 Ответ

1 голос
/ 10 мая 2009

Ваше решение здесь - это действительно модульные тесты ваших запросов в сочетании с постоянной интеграцией . У вас есть запросы в виде кода JDBC. Достаточно легко написать модульные тесты для подключения к вашим соответствующим базам данных и выполнения запросов таким образом, чтобы вы хотя бы увидели, выполняются ли они, даже если вас не интересуют результаты, о которых вы говорите, это стандарт .

Возможно, вы можете расширить это, чтобы измерить производительность и / или результаты, но я считаю, что такого рода тесты чрезвычайно хрупкие и имеют тенденцию очень и очень быстро ломаться, так как неизбежно происходит больше изменений.

...