Информация

Дата основания
Местоположение
Россия
Сайт
jetbrains.com
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 23
сейчас бы в 2020 для монго писать на скл

Обалдеть сколько вкусного завезли!
Отдельное спасибо за форматирование в max view!

А поддержка Redis планируется из коробки?

Периодически обсуждаем и помним, но конкретных планов пока нет.
Если в ячейке хранится однострочный XML или JSON, в редакторе значений он будет показан в отформатированном виде. Причем вы можете отредактировать значение в удобном виде, а сохранится оно всё равно как одна строка.

image


Этой фичи реально не хватало. DataGrip лучшее что случилось с софтом для DBA

Единственная проблема которая останавливает меня от пользования DataGrip была заведена еще 2 года назад — DBE-6807. И судя по статусу до сих пор не решена.

Поправьте плиз настройки временной зоны, т к таймстемпы отображаются со слона по умолчанию как 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""}"));
Огромное спасибо за SQL к mongodb!!!
При запросе к mongodb порядок полей в результирующей таблице не соответствует порядку указанному в запросе.
Более того, если руками переставить в ответе, то после выполнения запроса опять всё переставится в алфавитный порядок…
Монга просто всегда отдает документ, с полями в алфавитном порядке и _id в начале. То есть, это фича реквест :)

И вообще порядок полей в JSON не определён.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.