Комментарии 23
Обалдеть сколько вкусного завезли!
Отдельное спасибо за форматирование в max view!
А поддержка Redis планируется из коробки?
youtrack.jetbrains.com/issue/DBE-283
* ему уже 6 лет, если чо
Если в ячейке хранится однострочный XML или JSON, в редакторе значений он будет показан в отформатированном виде. Причем вы можете отредактировать значение в удобном виде, а сохранится оно всё равно как одна строка.
Этой фичи реально не хватало. DataGrip лучшее что случилось с софтом для DBA
Поправьте плиз настройки временной зоны, т к таймстемпы отображаются со слона по умолчанию как UTC, хотя сам слон настроен на временную зону Москвы.
Долго искали причину таких аномалий-думали может в слоне что.
Оказалось в настройках по умолчанию данного IDE почему-то ставится UTC.
В бобре и пгадмине таких проблем нет.
1. У PostgreSQL в драйвере JDBC нет возможности узнать дефолтную тайм-зону сервера, которая там хранится в конфиг-файле. Просто нет. На гитхабе можно найти соответствующий тикет с огромной дискуссией. Тикет, кстати, закрыли, хотя делать не стали.
github.com/pgjdbc/pgjdbc/issues/576
2. Итак, когда DataGrip подключается к базе при помощи jdbc, нужно выставить какую-нибудь тайм-зону. Мы выставляем UTC. Если этого не сделать, то тайм-зона выставится автоматически, и она возьмётся из процесса. То есть, грубо говоря, проставится тайм-зона той машины, откуда запускается DataGrip. Но это еще хуже, чем UTC, потому что пользователь этого не ожидает. У нас раньше именно так и работало и к нам чуть ли не ежедневно приходили пользователи, которые не понимали что происходит. Мы долго думали и решили, что UTC — вариант, вызывающий наименьшее количество проблем.
3. Что делать тем, кому UTC не подходит? Выставлять тайм зону явно, для этого мы сделали UI: intellij-support.jetbrains.com/hc/user_images/D0Mif8Q0HMgqWufc0v2FpQ.png
4. Как же тогда работает DBeaver, если он тоже использует JDBC? А он-то как раз берет таймзону локальной машины, и ничего не знает про тайм-зону сервера, потому что и не может знать (см пункт один). Просто в вашем случае вы запускаете DBeaver из России, и ваша база имеет ту же таймзону по умолчанию. То есть, это просто совпадение.
ИТОГ: Пока в драйвере не сделали возможность узнавать про тайм зону сервера, текущее решение наименее проблемное. А вам надо проставить тайм-зону Москвы во вкладке Options.
Благодарю за развернутый и аргументированный ответ.
Однако, если это не специальные поля для обработки, то обычно как раз таки время берется локальное, которое на локальной машине, откуда пошел запрос, а не время сервера.
Т е человек делает запись и отображаемое время создания записи ожидается такое, какое было у пользователя на момент создания записи.
Для унификации порой вводят ещё одно специальное поле, которое хранит время в формате UTC для последующих обработок с разными временными зонами.
Или же вообще хранят все в UTC, а при отображении конвертируют в нужное время, опять же исходя из локальных настроек устройства пользователя, а не сервера. Было бы странным пользователю видеть время сервера.
Обычно, если пользователи в разных часовых поясах, то пишется какое-то стандартное время: юникс-эпоха, UTC, московское встречал, время главного офиса, и обычно именно его выставляют на сервере и отдают в ответах на запросы на уровне базы, даже если сервер на другом полушарии. Уже приложение конвертирует, если надо беря из настроек пользователя часовую зону или из поля соседнего с временем.
Да, но так, чтобы не удивлять пользователя (разработчика и аналитика в том числе), т к он хочет видеть свое время локальное.
В любом случае решение у бобра самое распространенное и им пользуется очень много людей+он есть бесплатный, есть и платный. Но бесплатного обычно хватает для большинства задач.
Ну вот я, как разработчик, сильно удивлюсь, если, подключившись к серверу с ЦА в США, увижу локальное время… Какое-нибудь тихоокеанское — нет, UTC — нет, а вот киевское...
Смотря какую задачу решаете
Но utc по умолчанию, это 100% не угадать, тогда как локальное время компьютера-как минимум 50% вероятности угадать.
И бобром много кто пользуется-если нужно время сервера, можно выставить в настройках для тех, у кого сервер не в их временной зоне или важно время сервера, а не локальное (в большинстве своем в маленьких и средних проектах как раз сервер в той же временной зоне, что и клиенты-даже если вся инфраструктура в облаке где-то в другом месте, то и клиенты и сервера будут там же, потому и будет 50%+ что у клиента, что на сервере один часовой пояс).
Потому из соображений юзабилити очень удивился, почему не перенять удачный опыт настроек всем известного в мире бобра
А как же запрос:
SELECT * FROM pg_timezone_names WHERE name = current_setting('TIMEZONE');
Который и выводит текущую временную зону.
По крайней мере именно так компоненты ИС узнают какая временная зона в слоне.
Уверен, что и бобер также узнает, т к сейчас проверил и он возвращает время именно сервера, а не клиента
Datagrip ужасно работает с композитными типами в PG.
К примеру, Data Extractor генерирует невалидный SQL, который сам помечает ошибочным.
Если сделать тип
create type public.composite_type as (
internal_value varchar[]
);И заполнить таблицу какими-то значениями
create table public.composite_test (
id bigint not null,
value public.composite_type not null
);То Data Extractor сгенерирует такой INSERT, например:
insert into public.composite_test (id, value) values (1234, ("{""тест текст 1"",""тест текст 2""}"));Ну, или можете сами подправить экстрактор :)
При запросе к mongodb порядок полей в результирующей таблице не соответствует порядку указанному в запросе.
Более того, если руками переставить в ответе, то после выполнения запроса опять всё переставится в алфавитный порядок…
DataGrip 2020.3: SQL для Монги, новые форматы экспорта, интроспекция прав доступа и другое