Использование двух разных баз данных с одинаковыми файлами отображения гибернации

Question

По сути, идея состоит в том, чтобы использовать одни и те же файлы отображения гибернации для двух разных базовых баз данных. В производственном процессе основной базой данных является MySQL5, и для целей тестирования я бы хотел использовать Apache Derby - чтобы избежать настройки и поддержки различных баз данных MySQL для целей тестирования.

Я надеялся, что простое переключение драйвера DataSource и изменение нескольких параметров сделают эту работу, но я уже столкнулся с некоторыми небольшими трудностями. Так что на самом деле есть два вопроса. Первый конкретный вопрос:

I. Можно ли указать Derby, какой тип данных использовать, если тип данных доступен в MySQL, а не в Derby. Отображение выглядит следующим образом:

  <property name="about">
    <column name="`about`" not-null="false" sql-type="text"></column>
  </property>

Дерби не знает sql-типа "текст", поэтому он отказывается создавать таблицу. Это Derby 10.4.2.0 и Hibernate 3.2.6. кстати.

II. Каков ваш опыт использования двух разных баз данных для тестирования и производства? Я знаю, что есть некоторые недостатки, например, вы не можете тестировать хранимые процедуры или запросы к базе данных - но с другой стороны, это делает тестирование проще и быстрее (если вы наконец запустили его). Что ты думаешь?

Answer 1

Вопрос № 1 - не указывайте тип sql; используйте Тип гибернации вместо:

<property name="about" type="string" length="4096"/>

Затем можно расширить диалект Derby (или MySQL), предоставляемый Hibernate, для сопоставления этого типа с соответствующим типом БД на основе (не) указанной длины. Взгляните на MySQLDialect для примера; он отображает строковый тип либо на varchar, либо на один из text типов в зависимости от длины.

Вопрос № 2 - Вы имели в виду использование разных баз данных для разработки и производства? Потому что использование разных баз данных для тестирования и производство - это как играть в русскую рулетку с полностью загруженным стволом - вы не выиграете: -)

Вам всегда нужно тестировать все применимые конфигурации развертывания. Использование разных БД для разработки и производства не является плохим подходом, если вам действительно необходимо поддерживать оба, так как это помогает быстро определить проблемы переносимости.

Answer 2

Не должно быть проблем с использованием разных поставщиков баз данных в разных средах (обратите внимание на ответ ChssPly76, что TEST и PROD должны быть одинаковыми). Хотя я еще не пробовал Дерби.

Лично мне нравится использовать HSQLDB для среды DEV. Он небольшой, гибкий и легко переносимый, не требующий настройки. Использование такого инструмента, как Unitils , чтобы склеить Hibernate, DbUnit и JUnit, отлично работает для меня. Перед выполнением тестов JUnit в HSQLDB загружаются данные статических тестов. Это позволяет тестам JUnit уровня доступа к данным иметь утверждения, основанные на реальных данных (он загружается из некоторых файлов XML, расположенных рядом с тестами).

(Одно слово предостережения в отношении Unitils - это то, что по умолчанию «loadStrategy» отбрасывает все существующие данные перед загрузкой, поэтому будьте осторожны, когда вы указываете на это).

Answer 3

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

Очевидно, что если вам нужна функция, специфичная для базы данных (хранимая процедура или даже специальный тип), вы должны использовать тот же тип.

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

Answer 4

По моему опыту, чем больше реализаций баз данных вы тестируете, тем быстрее вы обнаружите места, где вы случайно зависели от чего-то, что не переносимо между базами данных.

Если Derby делает ваше тестирование быстрее и проще, то это отличный результат, так как более быстрое и простое тестирование способствует большему тестированию.

Я думаю, что Derby - отличный выбор для тестирования, поскольку Derby очень старается соответствовать стандарту SQL и поддерживать только синтаксис и поведение, указанные в стандарте, поэтому это должно помочь вам избежать использование нестандартных функций базы данных.

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