Comments 11
Cпасибо за интересную идею. Ее как оказалось мы не смотрели при отборе вариантов. Но тут есть момент: время то полностью заморозится в таком случае. А нам нужно чтобы оно продолжало тикать и после модификации.

Вообще обычно правильнее использовать в своём коде свою кастомную функцию вместо sysdate/current_xxx. Это наиболее распространённый, простой и гибкий подход.

Пфф, как не красиво. Зачем делать для прода кастомную функцию, которая заменяет собой системные функции (и при этом на проде время не нужно менять)?
Если переписывать вообще все что есть на тестовой среде под такие требования — код будет от прода отличаться. К тому же никто не сможет запретить написать код без использования кастом функции для времени. Спасибо, но нет.

Я себе это вижу немного по-другому. Везде в коде использовать кастомную функцию. А вот на тесте — внутри нее идет переопределение даты. А на проде она дальше каскадно вызывает системную функцию. Проблема в том, что каждую функцию, которую нужно переопределить, придется оформить таким образом. И не дай Бог случайно воспользоваться штатными функциями работы с датой. По сути — изобретаем свой язык поверх стандартного языка ) Можно? Можно. Сложно? Да.

Можно, но SQL-запросы со стандартной функцией даты и с кастомной начнут совсем по-разному оптимизироваться. И налететь на проблемы можно очень легко

Вы работаете только с локальным каким-то бизнесом без интернализации и сложных финансовых проводок? Дело в том, что sysdate/systimestamp — не бизнесовые даты. На самом деле, очень много различных тонкостей бывает, начиная со смены таймзоны (летнее/зимнее/отмена летнего/миграция/расширение в другой регион и тд) и заканчивая отложенных или будущих операций. Sysdate/systimestamp пойдут для обычного логгинга или другого не особенно завязанного на время функционала, но не для бизнес операций, как например, тот же опердень в банкинге. Своя кастомная функция позволяет это все строго формализовать в одном месте.

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

Очень интересный и полезный опыт!


Но хочу уточнить:


были проверены системы легкой виртуализации (Vserver, OpenVZ) и контейнеризации через docker. Тоже не работает, они используют то же самое ядро что и хост-система, а значит используют те же значения системного таймера. Снова отпадает.

Да, ну? У вас ниже в статье по сути идёт подгрузка faketime, а ядро общее. Так что это в каком-то смысле противоречие. Ну, и раз докер работает через cgroups/namespaces, то прямолинейным выглядит путь как по ссылке https://lwn.net/Articles/766089/

И тут тоже спасибо за подсказку. Этого никто в нашей команде не находил во время отбора гипотез. Но оно будет работать только если экземпляры базы данных разные и запущены как разные контейнеры, а для cdb/pdb опять бы пришлось все равно делать что-то свое.
Добрый день!
На уровне экземпляра (не знаю, как работает в PDB, думаю, затронет только конкретный контейнер) можно еще использовать:
alter system set fixed_date = '2017-04-01 12:34:56';
и затем после тестов
alter system set fixed_date = 'NONE';
Only those users with full accounts are able to leave comments. Log in, please.