JDBC переводит в таймзону клиента из UTC, и плюет на тип, ему без разницы что DateTime что DateTime('Europe/London')

таймзона это свойство типа DateTime (тип колонки), одно на всю колонку

Точнее даже не так. JDBC всегда переводит в таймзону клиента, если получает колонку DateTime, то переводит из таймзоны сервера в таймзону клиента, если получает DateTime('Europe/London') , переводит из Europe/London в таймзону клиента

в jdbc есть настройка на то, чтобы использовать TZ сервера

Задача наблюдать динамику роста ивентов относительно друг друга т.е. по сути на одном графике

Я примерно то же самое пытался сделать, в итоге оказалось проще селектать
time key value и делать pivot уже в go(заменить на java, c, на чем у вас бек), потому что у меня key было штук 20к и  оверхед на массивы был слишком большой.

Добрый день.
немного дикий вопрос.
Мы кликхаус разворачиваем в организации для промышленных решений, и нас троллят безопасники тем что там нет ограничений по парольной политике, можно для dba создать пароль 123, нет срока действия пароля, нет запрета на переиспользование пароля и т.д.
как вы боретесь с проблемой несанкционированного доступа? то есть что кто угодно может просто подобрать пароль к БД

если общение по http идет, то можно в какой нибудь прослойке такое организовать.
У нас допустим до chproxy одни пароли, а после другие.
А так ограничения по разрешенным сетям и тд

А кто как организует у себя миграции в КХ в jenkins ? есть ли какие то best practices или что то по типу этого ?

та настройка говорит не спрашивай таймзону у сервера, возьми из use_time_zone, это ничего не изменит для DateTime('Europe/London')

у меня ключей не сильно мноко пока, так что с массивами вроде норм работает. Вот тут хорошо обьяснили как все нужно закрутить https://github.com/ClickHouse/ClickHouse/issues/1469#issuecomment-387693522

SELECT toDateTime(now(), 'Europe/London')

┌─toDateTime(now(), 'Europe/London')─┐
│                2020-05-29 15:07:15 │
└────────────────────────────────────┘

SELECT toString(now(), 'Europe/London')

┌─toString(now(), 'Europe/London')─┐
│ 2020-05-29 15:09:11              │
└──────────────────────────────────┘


через jdbc
select toDateTime(now(), 'Europe/London')
2020-05-29 11:07:25

select toString(now(), 'Europe/London')
2020-05-29 15:08:59

А если мне важно фильтровать/группировать по дате в таймзоне Москвы? У меня есть колонка в UTC с временем завершения заказа. Хочу знать, сколько заказов было сегодня (в Московской зоне)

Если в поле UInt8 добавить значение 999, оно будет сохранено как 231. Не подскажете, есть ли возможность получать ошибку если инт выходит за диапазон поля? Типа strict mode.

нету такой проверки, нету strict mode

констреинт на каком моменте срабатывает?

Интересно, почему в КХ запрос
SELECT count(*) AS count FROM (SELECT number FROM system.numbers LIMIT 102400) FORMAT JSON
выполненый через clickhouse-client выдает такой ответ
{
 "meta":
 [
   {
     "name": "count",
     "type": "UInt64"
   }
 ],

 "data":
 [
   {
     "count": "102400"
   }
 ],

 "rows": 1,

 "rows_before_limit_at_least": 131072,

 "statistics":
 {
   "elapsed": 0.002607934,
   "rows_read": 131072,
   "bytes_read": 1048576
 }
}
Почему значение "count" это строка?
Версия 20.3.7.46

есть настройка для UInt64

потому что javascript не умеет UInt64

--output_format_json_quote_64bit_integers -- в доке все описано