AG
короче если там реально много данных и они постоянно меняются и сервис критичен к прерыванию, я бы сказал что это сложная задачка для решения в одно лицо
Задачка и вправду сложная. Уточню тогда можем ли остановить БД на некоторое время
Size: a a a
2021 March 23
AG
Tim Ami
Жить на монге дальше, при таких вводных цена решения скорее всего будет неприемлема
К сожалению как говорят монго плохо работает на больших нагрузках
AK
Задачка и вправду сложная. Уточню тогда можем ли остановить БД на некоторое время
ну гасить-то надо не бд, а приклад. чтобы не было момента несогласованности данных.
AG
ну гасить-то надо не бд, а приклад. чтобы не было момента несогласованности данных.
Ну да, я имел ввиду сервис
AG
Ок, спасибо
VP
К сожалению как говорят монго плохо работает на больших нагрузках
А вы переезжаете основываясь на том, что где-то говорят, или это ваше нагрузочное тестирование говорит, что она скоро перестанет вывозить?
AG
А вы переезжаете основываясь на том, что где-то говорят, или это ваше нагрузочное тестирование говорит, что она скоро перестанет вывозить?
Мне сказали что данные теряются
D
Подскажите, пожалуйста, кто как решает проблему перезапуска TestContainers после @DirtiesContext?
У меня есть много тестов, которые используют БД для чтения оттуда данных, но есть и несколько тестов, которые пишут в БД и это ломает читающие тесты, т.к. появляются неожиданные для них данные.
Скажем так, проблема в том, как остановить статический контейнер. Есть мысли сделать хак из бина в котором в @PreDestroy стонать контейнер, а поднимится он сам, когда новый контекст будет создаваться. Но, может, есть более элегантный способ?
У меня есть много тестов, которые используют БД для чтения оттуда данных, но есть и несколько тестов, которые пишут в БД и это ломает читающие тесты, т.к. появляются неожиданные для них данные.
Скажем так, проблема в том, как остановить статический контейнер. Есть мысли сделать хак из бина в котором в @PreDestroy стонать контейнер, а поднимится он сам, когда новый контекст будет создаваться. Но, может, есть более элегантный способ?
если это актуально
DE
@volalex @dmsol я забыл упомянуть, что у меня типа интеграционрого тестирования, я webClient'ом дёргаю endpoint, transactional может сработать для случая с сервисами, когда изнутри тестируешь, за эту идею спасибо, но не в моей ситуации. TearDown и чистка БД вручную более трудозатратный вариант.
В идеале хочется подцепиться к прослушиванию life cycle контекста приложения и стопать контейнер, когда application context уничтожается
В идеале хочется подцепиться к прослушиванию life cycle контекста приложения и стопать контейнер, когда application context уничтожается
AE
короче если там реально много данных и они постоянно меняются и сервис критичен к прерыванию, я бы сказал что это сложная задачка для решения в одно лицо
У нас миграция планируется на прод, в выходные на тесте бежала почти 36 часов)
На проде так же на все выходные запустим)
На проде так же на все выходные запустим)
A
Подскажите, пожалуйста, кто как решает проблему перезапуска TestContainers после @DirtiesContext?
У меня есть много тестов, которые используют БД для чтения оттуда данных, но есть и несколько тестов, которые пишут в БД и это ломает читающие тесты, т.к. появляются неожиданные для них данные.
Скажем так, проблема в том, как остановить статический контейнер. Есть мысли сделать хак из бина в котором в @PreDestroy стонать контейнер, а поднимится он сам, когда новый контекст будет создаваться. Но, может, есть более элегантный способ?
У меня есть много тестов, которые используют БД для чтения оттуда данных, но есть и несколько тестов, которые пишут в БД и это ломает читающие тесты, т.к. появляются неожиданные для них данные.
Скажем так, проблема в том, как остановить статический контейнер. Есть мысли сделать хак из бина в котором в @PreDestroy стонать контейнер, а поднимится он сам, когда новый контекст будет создаваться. Но, может, есть более элегантный способ?
Ты в тех ломающих тестах можешь отдельно подымать контейнер с базкой и тогда для них каждый раз будет запускатся свой контейнер, по времени исполнение это конечно ударит, ну или руками клинапить
A
Подскажите, пожалуйста, кто как решает проблему перезапуска TestContainers после @DirtiesContext?
У меня есть много тестов, которые используют БД для чтения оттуда данных, но есть и несколько тестов, которые пишут в БД и это ломает читающие тесты, т.к. появляются неожиданные для них данные.
Скажем так, проблема в том, как остановить статический контейнер. Есть мысли сделать хак из бина в котором в @PreDestroy стонать контейнер, а поднимится он сам, когда новый контекст будет создаваться. Но, может, есть более элегантный способ?
У меня есть много тестов, которые используют БД для чтения оттуда данных, но есть и несколько тестов, которые пишут в БД и это ломает читающие тесты, т.к. появляются неожиданные для них данные.
Скажем так, проблема в том, как остановить статический контейнер. Есть мысли сделать хак из бина в котором в @PreDestroy стонать контейнер, а поднимится он сам, когда новый контекст будет создаваться. Но, может, есть более элегантный способ?
@bsideup как бы ты делал ?
A
или его уже тута нету ? :( печааль
AG
Так просто нужно чистить базу, не пересоздавая контейнер, если я правильно понял проблему.
DE
Нужно чистить не всю базу. Т.к она для тестов частично Liqubase накатывается.
AG
Тогда ещё проще. У liquibase в спринге есть параметр drop-first. Если поставить его в true, то liquibase будет удалять все данные и схему, а потом перенакатывать на каждое создание контекста
AG
У нас миграция планируется на прод, в выходные на тесте бежала почти 36 часов)
На проде так же на все выходные запустим)
На проде так же на все выходные запустим)
36 часов это овер до фига )) как вы будете решать проблему новых записей во время миграции?
AE
36 часов это овер до фига )) как вы будете решать проблему новых записей во время миграции?
У нас в выходные никто не пользуется системой)