Простой способ усечь все таблицы, очистить кэш первого и второго уровня?

Question

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

Мне было интересно, существует ли эффективный способ попросить Hibernate удалить все из базы данных и кешей.Лучшее, что я мог придумать, это использовать HQL-строку «delete from XImpl» для каждого типа объектов, но у меня есть пара десятков доменных объектов, и кажется, что должен быть лучший способ.

Answer 1

Для базы данных используйте инструмент SchemaExport для воссоздания схемы:

Configuration cfg = ....;
new SchemaExport(cfg).create(false, true);

Для кэша 2-го уровня получите доступ к базовым областям кэша из SessionFactory и удалите все:

SessionFactory sf = ...;
Cache cache = sf.getCache();
cache.evictEntityRegions();
cache.evictCollectionRegions();
cache.evictQueryRegions();

Для кэша 1-го уровня, просто получите новый Session или позвоните session.clear().

Answer 2

Взгляните на Unitils . Он прекрасно поддерживает тестирование базы данных (с использованием DbUnit), которое мы использовали довольно давно. Он действительно гибкий, поэтому вы можете использовать его, если вам когда-нибудь понадобится предварительно загрузить данные в базу данных для конкретных модульных тестов.

С помощью Unitils вы создадите файл набора данных (empty-db.xml), представляющий пустую базу данных:

<?xml version='1.0' encoding='UTF-8'?>
<dataset>
  <obj1/>
  <obj2/>
</dataset>

На классах или тестах, где необходимо настроить набор данных

@DataSet("empty-db.xml")

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

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

Положительным моментом, особенно для большой схемы, является то, что это намного быстрее, чем перестройка схемы.

Answer 3

Используя подход Паскаля, описанный выше, я искал правильный способ создания объекта SchemaUpdate в Spring и понял, что мне это не нужно.Вместо этого я могу просто получить объект SpringFactory для Hibernate в Spring и попросить его удалить / создать схему.Объединяя это с остальной частью решения Паскаля, мы получаем это:

LocalSessionFactoryBean localSessionFactoryBean = (LocalSessionFactoryBean)appContext.getBean("&sessionFactory");
localSessionFactoryBean.dropDatabaseSchema();
localSessionFactoryBean.createDatabaseSchema();
Cache cache = sf.getCache();
cache.evictEntityRegions();
cache.evictCollectionRegions();
cache.evictQueryRegions();

Это довольно эффективно.Единственным недостатком является то, что (по крайней мере для меня) это заметно медленнее, чем вызов «delete from obj1», «delete from obj2» для каждого имени таблицы.Тем не менее, мне нравится не повторяться.