Да, видимо это не та статья которую вы хотели увидеть. Статья действительно не техническая, но она и заявлена как кейс. На мой персональный взгляд чтиво отличное, и его цель скорее заинтересовать отраслью и убедить соменвающихся, что все это действительно перспективное направление для развития. Сугубо технические статьи не способствуют росту комьюнити, нацеленного на подобные технологии.
А можно как-то подробнее? Задача выглядит как супер-стандартная и решаемая Liquibase-ом. Очень хочется чтобы была раскрыта тема сравнения с Flyway и Liquibase.
P.S. Пункт "желание не использовать коробочные решения, а еще разбавить поток бизнес-задач разработкой инструмента" из дано вглядит крайне дико и наталкивает на мысли, что на анализ существующих решений не было потрачено необходимого времени.
Спасибо за статью! Рады делать полезный продукт :). Хотелось бы заметить, что дифференциальные скрипты для Flyway и для Liquibase получать можно совсем в автоматическом режиме.
Честно, на костыль похоже подстановка локальной тамзоны, при явном отсутствии таковой. Есть даже статья Влада Михалчи, где про это явно говорится. Еще он упоминает, что далеко не все драйвера БД проставляют локальную тамзону. Вся история учит нас отказываться от дефолтов, причем плавающих (зависящих от подключенных зависимостий например).
Мне пришлось много поработать со временными полями и должен сказать, что практически всегда в итоге приходилось отказываться от локального времени вообще. Либо храним в UTC и переводим в нужную локаль на презентационном слое, либо храним полностью с часовым поясом. В противном случае мы завязываемся на внешние факторы. Например, непредсказуемые переводы времени. Да-да, бывает и такое. Когда все сервера думают, что надо переводить время с 2am на 1am, а локальные законы (это было с проектом в Ливане) делают это с 1am на 12pm (т.е. фактически переводят и день). И все заказы такси летят к чертям :). Также были случаи подения серверов, а при переподнятии невыставление правильной локали.
Спасибо вам большое за терпение, я проведу еще несколько консультаций со сторонними экспертами, чтобы окончательно решить как нам быть :). Так-то поменяем, в чем проблема :).
Надеюсь вы не используете Instant как замену LocalDateTime?
Очевидно что нет.
Для timestamp типа postgres не передает временную зону, потому бекенд использует текущую.
Чтобы не было проблем работы в разных таймзонах и не было преобразование времени из локали JVM в локаль DB и обратно есть такое замечательное свойство: spring.jpa.properties.hibernate.jdbc.time_zone=UTC.
Ээээ. Так все же верно. Сохраняем с клиента инстант 29.01.2022 15:40 UTC. Ровно это значение получаем в базе. Ровно это знаение и зачитываем из базы. Таймзоны для работы в UTC вообще не причем. Их просто нет. Всегда +00.
Что значит "бэкенд интерпретирует это значение в своей временной зоне"?
Честно, я не понимаю почему это может привести к неразберихе, даже если бэкеды будут в разных таймзонах. Время из инстанта не пересчитывается в локальную таймзону сервера. Вот прямо сейчас сделал тест. В обеих базах ровно одно и то же значение, как и при чтении. Попробовал Oracle, PostgreSQL 13, MS SQL.
Ведь вопрос с маппингом дат касается не только reverse-engineering, но и генерации migration на основе наших Entity.
Спасибо большое, что не поленились и все написали :)!
Да, я понимаю ваш кейс. Мы так изначально и думали. Но все же в общем случае это именно инстатнт. Давайте посмотрим на примеры.
Мы ставим отметку времени получения данных - это именно момент времени или Instant. Мы фиксируем дату и время принятия документов в посольство и это Instant. Фиксируем дату нарушения ПДД - Instant. Т.е. это характеристика некоторого события. И, как выяснилось, это и есть основные кейсы.
Кейсы, подходящие под вашу логику такие: Студент должен подать документы на поступление в ВУЗ до 10:00 утра. И таквезде, т.к. это распоряжение МинОбраза. В Москве, Самаре, Воронеже,... Это и есть LocalDateTime. И, количественно, по нашим изысканиям, такие кейсы уступают упомянутым выше.
Однако, было понятно, что такой подход устроит не всех. Вот вас например не устроил :). Поэтому предусмотрена возможность переопределить дефолтный маппинг. Описано это это в доке: https://www.jpa-buddy.com/documentation/database-versioning/#custom-type-mappings. Просто добавьте туда маппинг, который считаете правильным и все.
Еще один способ, когда ваши колонки в базе типа timestamp интерпритируется "то так, то так", то можно вборочно обойтись добавлением columnDefinition.
Можно. Возможно так и сделаем. Но по опыту своему и опыту многих коллег, связанных с OS, ожидания от контрибьюшена со временем множатся на 0, а серьезный оверхед от разделения на модули и использования разной инфраструктуры остается.
Задача держать плагин максимально доступным, соответственно, разрабатывать его компактной командой. Т.о. плодить оверхеда без очевиных преимуществ не выглядит возможным.
Спасибо! Но это не отменяет того, что поведение не должно зависить от типа FetchType. А потом в Spring Data кто-то определяет EntityGraph и все снова летит к чертям...
Именно! И современные требования бизнеса зачастую монолитом недостижимы. Кстати, вот вы что считаете "реально полезное с микросервисов"?
И не читал вот эту статью: https://habr.com/ru/companies/haulmont/articles/579386/.
Конечно есть! Вот тут за 2 мин показано как оно работает https://www.youtube.com/watch?v=1D5zEzLX1iY.
Все микросервисы которые я вижу в последнее время тоже лежат в монорепе.
Да, видимо это не та статья которую вы хотели увидеть. Статья действительно не техническая, но она и заявлена как кейс. На мой персональный взгляд чтиво отличное, и его цель скорее заинтересовать отраслью и убедить соменвающихся, что все это действительно перспективное направление для развития. Сугубо технические статьи не способствуют росту комьюнити, нацеленного на подобные технологии.
Спасибо за ответ!
А что за модули приложения? Так-то в ликвибейз и джава код выполнять можно...
По моему опыту освоение Liquibase у человека со знанием SQL занимает максимум неделя.
Зависить от вендора опесорсного решения? Так все и так от них зависят :).
А можно как-то подробнее? Задача выглядит как супер-стандартная и решаемая Liquibase-ом. Очень хочется чтобы была раскрыта тема сравнения с Flyway и Liquibase.
P.S. Пункт "желание не использовать коробочные решения, а еще разбавить поток бизнес-задач разработкой инструмента" из дано вглядит крайне дико и наталкивает на мысли, что на анализ существующих решений не было потрачено необходимого времени.
Пишите, если будут идеи о том как бы еще упростить жизнь коллег :)
Flyway c Июня 2021 :)
Спасибо за статью! Рады делать полезный продукт :). Хотелось бы заметить, что дифференциальные скрипты для Flyway и для Liquibase получать можно совсем в автоматическом режиме.
Честно, на костыль похоже подстановка локальной тамзоны, при явном отсутствии таковой. Есть даже статья Влада Михалчи, где про это явно говорится. Еще он упоминает, что далеко не все драйвера БД проставляют локальную тамзону. Вся история учит нас отказываться от дефолтов, причем плавающих (зависящих от подключенных зависимостий например).
Мне пришлось много поработать со временными полями и должен сказать, что практически всегда в итоге приходилось отказываться от локального времени вообще. Либо храним в UTC и переводим в нужную локаль на презентационном слое, либо храним полностью с часовым поясом. В противном случае мы завязываемся на внешние факторы. Например, непредсказуемые переводы времени. Да-да, бывает и такое. Когда все сервера думают, что надо переводить время с 2am на 1am, а локальные законы (это было с проектом в Ливане) делают это с 1am на 12pm (т.е. фактически переводят и день). И все заказы такси летят к чертям :). Также были случаи подения серверов, а при переподнятии невыставление правильной локали.
Спасибо вам большое за терпение, я проведу еще несколько консультаций со сторонними экспертами, чтобы окончательно решить как нам быть :). Так-то поменяем, в чем проблема :).
Очевидно что нет.
Чтобы не было проблем работы в разных таймзонах и не было преобразование времени из локали JVM в локаль DB и обратно есть такое замечательное свойство:
spring.jpa.properties.hibernate.jdbc.time_zone=UTC.Ээээ. Так все же верно. Сохраняем с клиента инстант 29.01.2022 15:40 UTC. Ровно это значение получаем в базе. Ровно это знаение и зачитываем из базы. Таймзоны для работы в UTC вообще не причем. Их просто нет. Всегда +00.
Что значит "бэкенд интерпретирует это значение в своей временной зоне"?
Честно, я не понимаю почему это может привести к неразберихе, даже если бэкеды будут в разных таймзонах. Время из инстанта не пересчитывается в локальную таймзону сервера. Вот прямо сейчас сделал тест. В обеих базах ровно одно и то же значение, как и при чтении. Попробовал Oracle, PostgreSQL 13, MS SQL.
Все так, поэтому настроить можно и там и там :).
Спасибо большое, что не поленились и все написали :)!
Да, я понимаю ваш кейс. Мы так изначально и думали. Но все же в общем случае это именно инстатнт. Давайте посмотрим на примеры.
Мы ставим отметку времени получения данных - это именно момент времени или
Instant. Мы фиксируем дату и время принятия документов в посольство и этоInstant. Фиксируем дату нарушения ПДД -Instant. Т.е. это характеристика некоторого события. И, как выяснилось, это и есть основные кейсы.Кейсы, подходящие под вашу логику такие: Студент должен подать документы на поступление в ВУЗ до 10:00 утра. И таквезде, т.к. это распоряжение МинОбраза. В Москве, Самаре, Воронеже,... Это и есть
LocalDateTime. И, количественно, по нашим изысканиям, такие кейсы уступают упомянутым выше.Однако, было понятно, что такой подход устроит не всех. Вот вас например не устроил :). Поэтому предусмотрена возможность переопределить дефолтный маппинг. Описано это это в доке: https://www.jpa-buddy.com/documentation/database-versioning/#custom-type-mappings. Просто добавьте туда маппинг, который считаете правильным и все.
Еще один способ, когда ваши колонки в базе типа timestamp интерпритируется "то так, то так", то можно вборочно обойтись добавлением columnDefinition.
Понял-понял. "Мопед не наш" :). Это окно из IntelliJ, попробуем что-то с этим сделать! Спасибо!
Спасибо! А можно поподробнее про настройку при каждом перезапуске? Напишите пожалуйста на info@jpa-buddy.com, будем очень благодарны!
Можно. Возможно так и сделаем. Но по опыту своему и опыту многих коллег, связанных с OS, ожидания от контрибьюшена со временем множатся на 0, а серьезный оверхед от разделения на модули и использования разной инфраструктуры остается.
Задача держать плагин максимально доступным, соответственно, разрабатывать его компактной командой. Т.о. плодить оверхеда без очевиных преимуществ не выглядит возможным.
@Filter вообще отлично работает взде, кроме... кэша :).
Спасибо! Но это не отменяет того, что поведение не должно зависить от типа FetchType. А потом в Spring Data кто-то определяет EntityGraph и все снова летит к чертям...