Я думал о создании новой, легкой базы данных о населении. Я абсолютно ненавижу dbunit. Прежде чем я это сделаю, я хочу знать, сделал ли это кто-то уже.
Что мне не нравится в dbunit:
1) Самый простой формат для написания и начала работы устарел. Они хотят, чтобы вы использовали раздутые форматы. Некоторые даже требуют XML-схем. Да, что угодно.
2) Они заполняют строки не в том порядке, в котором вы их пишете, а в таблицах порядка, определенных в файле XML. Это действительно плохо, потому что вы не можете упорядочить данные таким образом, чтобы ограничения внешнего ключа не вызывали проблем. Это просто вынуждает вас пройти через весь процесс их полного выключения.
Это также тратит впустую время и раздувает ваши базовые классы junit, чтобы включить код для отключения ограничений внешнего ключа. Вам, вероятно, придется проверить тип базы данных (hsqldb и т. Д.) И отключить их специфичным для базы данных способом. Это очень плохо.
Может быть, лучше, если dbunit автоматически отключит ограничения внешнего ключа как часть их инфраструктуры, но они этого не делают. Они следят за диалектами ... так почему бы не использовать их для этого? В конечном итоге все это заставляет программиста тратить время, а не быстро вставать и тестировать.
3) XML - это трудная задача. Мне не нужно больше говорить об этом. Они также предлагают так много способов сделать это, что я думаю, что это только усложняет ситуацию. Просто предложите один действительно надежный способ и покончите с этим.
4) Когда ваши данные становятся большими, слежение за идентификаторами и их последовательными / правильными отношениями - это королевская боль.
Кроме того, если вы не работали над проектом в течение месяца, как вы помните, что user_id 1 был администратором, user_id 2 был бизнес-пользователем, user_id 3 был инженером, а user_id 4 был чем-то другим? Возвращаясь, чтобы проверить, что это напрасная трата времени. Должен существовать осмысленный способ получить его, кроме произвольного числа.
5) Это медленно. Я обнаружил, что если не использовать hsqldb, он мучительно медленный. Это не должно быть. Есть также множество способов испортить его конфигурацию, так как это не так просто сделать «из коробки». Есть горб, через который вы должны пройти, чтобы заставить его работать правильно. Все, что это делает, - это побуждает людей не использовать его, или раздражаться, когда он начинает его использовать.
6) Некоторые значения часто повторяются, например даты. Было бы неплохо указать значения по умолчанию или даже сделать так, чтобы фреймворк автоматически вводил значения по умолчанию, даже если вы не сказали, чтобы они вводили значения по умолчанию. Таким образом, вы можете создавать объекты только с теми значениями, которые вам нужны, а оставшиеся отключены. Это наверняка лучше, чем указывать каждый закоулок колонны, если это не требуется.
7) Вероятно, наиболее раздражает то, что первая запись должна включать ВСЕ значения - даже нулевые заполнители - или будущие строки не будут выбирать столбцы, которые вы фактически указали.
DBunit также не имеет разумного значения по умолчанию для перевода [NULL] в реальное нулевое значение. Вы должны добавить его вручную. Скажите, кто не делал этого с dbunit? Каждый имеет. Так не должно быть!
Это означает, что если у вас есть полиморфный объект, вы должны объявить все внешние ключи для таблиц присоединения каждого подкласса в первой строке, даже если они имеют значение null. Если вы создаете таблицу для всех шаблонов подклассов, вам все равно нужно указать все поля в первой строке. Это просто ужасно.
Есть что-нибудь, что могло бы удовлетворить меня, или я должен стать следующим разработчиком фреймворка для гораздо лучшей фреймворк для тестирования баз данных?