это очень печально

Адрес deb репозитория с пакетами был изменён: https://clickhouse.yandex/#quick-start

Адрес deb репозитория с пакетами был изменён: https://clickhouse.yandex/#quick-start

А что это означает? что то изменить нужно?

это очень печально

и не такое бывало!

это очень печально

Ну я сначала удивился - а потом просто подправил свою роль для ансибла и живу дальше

печально что у меня сначала сломались плейбуки а только потом я узнал что они изменились и через 2 дня я увидел пин.

ещё оправдание — это, простите, международная практика, докер тоже так менял адреса репозиториев, с тем же откликом в сообществе

Изменилась вот эта строка. Теперь так: deb http://repo.yandex.ru/clickhouse/deb/stable/ main/ Это то, что прописывается в /etc/apt/sources.list или указывается в apt-add-repository.

Изменилась вот эта строка. Теперь так: deb http://repo.yandex.ru/clickhouse/deb/stable/ main/ Это то, что прописывается в /etc/apt/sources.list или указывается в apt-add-repository.

для плейбуков ансибла это привело к тому что приходится делать миграцию для этого дела...

ибо старый файл по умолчанию остаётся а новый не выглядит сильно олично. поэтому apt update падает ага.

Зато в новом репозитории сохраняются все версии пакетов, а не только последние.

и для решения надо удалить старый файл.

Зато в новом репозитории сохраняются все версии пакетов, а не только последние.

еще я заметил что там нет разделения на версии осей

это значит что на деб 8 и 9 встанет одинаковый кх ?

и для решения надо удалить старый файл.

Да, все верно. через apt_repository через absent работает

неужели на aptly переехали

Почему сделано изменение? Нам было необходимо, чтобы: 1. Все версии пакетов хранились вечно. Раньше в репозитории была только одна, последняя версия. 2. Убрать разделение по ОС (precise/trusty/xenial), так как пакет для всех систем стал одинаковым. Почему изменение сделано несовместимым образом? Тот, кто разбирается в настройке .deb репозитория утверждает, что вариант с изменением адреса - это единственный способ.

вопросов почему нету. есть печаль про уведомление :)

а репозитория для centos не планируется?

там какая то мутная тема. но в целом есть альтинити

Там же был какой-то неофициальный, собирал кто-то из сорцов вроде

но там стремный пакет с граблями при обновлении

я не хочу брать от неизвестно кого сборку

альтинити не неизвестно кто

команду посмотри там. думаю ты там всех знаешь :)

https://www.altinity.com/team/

Почему сделано изменение? Нам было необходимо, чтобы: 1. Все версии пакетов хранились вечно. Раньше в репозитории была только одна, последняя версия. 2. Убрать разделение по ОС (precise/trusty/xenial), так как пакет для всех систем стал одинаковым. Почему изменение сделано несовместимым образом? Тот, кто разбирается в настройке .deb репозитория утверждает, что вариант с изменением адреса - это единственный способ.

Что мешает для совместимости просто добавлять 1 и тот же пакет в разные репозитории?

Репозитории это святое, только утром хотел проверить есть ли в нем ваши другие продукты для кх (jdbc, odbc) но руки не дошли

Изменилась вот эта строка. Теперь так: deb http://repo.yandex.ru/clickhouse/deb/stable/ main/ Это то, что прописывается в /etc/apt/sources.list или указывается в apt-add-repository.

Т.е. с ключами больше ни у кого проблем нет?

Т.е. с ключами больше ни у кого проблем нет?

ключи не менялись же

Т.е. с ключами больше ни у кого проблем нет?

По прежнему weak-key

ключи не менялись же

W: GPG error: http://repo.yandex.ru/clickhouse/deb/stable main/ Release: The following signatures were invalid: 9EBB357BC2B0876A774500C7C8F1E19FE0C56BD4 у меня вот такое после смены репы. Удалять и импортировать ключ я пробовал.

По прежнему weak-key

Возможно, в Deb9 оно считается неприличным.

E0C56BD4 key же. нет ?

- name: Install by APT | Apt-key add yandex repo key apt_key: keyserver: keyserver.ubuntu.com id: E0C56BD4 become: true

а репозитория для centos не планируется?

https://packagecloud.io/altinity/clickhouse

Что мешает для совместимости просто добавлять 1 и тот же пакет в разные репозитории?

Зачем их несколько поддерживать, лучше сразу один "отстрелить" и все. Сейчас с единым репозиторием для всех debian based бедут удобнее. При этом многие вообще пользуются своими репозиториями, что тоже правильно.

Странно ломать то что ничего не стоит не ломать

привет всем! сможет кто-то глянуть ПР на clickhouse-jdbc? https://github.com/yandex/clickhouse-jdbc/pull/186

Anton а можете еще правило для joda time добавить? или просто все в один путь положить? просто чтоб наверняка

joda time попадает в ru.yandex.repackaged.org

а, точно, по имени класса же

я посмотрел на группу и запутался)

ну да. я у себя какими-то костылями зафорсил версии так, что вроде все +- стабильно, но ощущение пороховой бочки осталось ?

я пробовал подложить 14 гуаву - драйвер упал с NoClassDeFound

E0C56BD4 key же. нет ?

Да, он и есть. Последние символы строки.

временно можно сделать так deb [trusted=yes] http://repo.yandex.ru/clickhouse/deb/stable/ main/

но это так себе решение

остается еще этот ворнинг W: Conflicting distribution: http://repo.yandex.ru/clickhouse/deb/stable main/ Release (expected main/ but got clickhouse stable), но с ним можно жить

временно можно сделать так deb [trusted=yes] http://repo.yandex.ru/clickhouse/deb/stable/ main/

Большое спасибо, работает. один из ворнингов: W: Conflicting distribution: http://repo.yandex.ru/clickhouse/deb/stable main/ Release (expected main/ but got clickhouse stable) я так понимаю, что это из-за "унификации"

ага

Я не поднимал репы, а разве сложно несколько папок сделать, хоть с симлинками?

а репозитория для centos не планируется?

Планируется. Есть пакеты, но мы ещё не успели их туда залить.

Про weak digest algorithm посмотрели и что-то исправили.

1. взять файл из clickhouse - debian/.pbuilderrc и положить его в -odbc в debian/.pbuilderrc 2. запустить: sudo DIST=artful ARCH=i386 pbuilder create —configfile debian/.pbuilderrc && DIST=artful ARCH=i386 pdebuild —configfile debian/.pbuilderrc 3 - вот он, /var/cache/pbuilder/artful-i386/result/clickhouse-odbc_1.1.1_i386.deb

Помогите, пожалуйста! После обновления до 1.1.54362 получаю ошибку Size of filter doesn't match size of column при работе со свежедобавленным столбцом с прописанным дефолтным значением (т.е. согласно документации, ch значение налету вычисляет для созданных ранее записей). Например, select sum(ve) from nr_views_t8 - так работает, а так нет: select sum(ve) from nr_views_t8 where a_s_o=1. ve UInt8 DEFAULT 1

Помогите, пожалуйста! После обновления до 1.1.54362 получаю ошибку Size of filter doesn't match size of column при работе со свежедобавленным столбцом с прописанным дефолтным значением (т.е. согласно документации, ch значение налету вычисляет для созданных ранее записей). Например, select sum(ve) from nr_views_t8 - так работает, а так нет: select sum(ve) from nr_views_t8 where a_s_o=1. ve UInt8 DEFAULT 1

Мы пока ещё не сталкивались с такой проблемой (хотя тоже недавно обновились до 54362). Поэтому нужна диагностика. Проверьте, не исчезает ли ошибка, если выставить SET optimize_move_to_prewhere = 0 Также попробуйте выбрать какой-нибудь минимальный кусок данных, на котором проявляется проблема. Как это сделать? Смотрите, какие есть куски данных с помощью SELECT * FROM system.parts WHERE active AND table = 'nr_views_t8'. name - это имя куска данных. В оригинальный запрос SELECT из nr_views_t8 можно добавить условие на кусок данных, вот так: ... AND _part = 'name' Если есть такой небольшой кусок данных, то вы можете достать его из файловой системы и переслать нам (clickhouse-feedback@yandex-team.ru). Понадобится также схема таблицы.

Я не поднимал репы, а разве сложно несколько папок сделать, хоть с симлинками?

Там не просто в папку закинул и всё. В общем решение сделать общий репозиторий правильное и рано или поздно это сделать бы пришлось. Единственное что это произошло несколько внезапно.

Коллеги, для КХ это стандартное поведение что при вставке поля DateTime КХ его модифицирует и приводит к своей таймзоне ?

можно ли через http запрос, как то указать КХ не модифицировать время

может при чтении преобразовывается дата к установленной таймзоне?

https://clickhouse.yandex/docs/ru/data_types/datetime/ По умолчанию клиент переключается на часовой пояс сервера при подключении. Это поведение можно изменить, включив у клиента параметр командной строки --use_client_time_zone.

А в случае вставки по http?

это на отображение влияет

хранится она в unix timestamp формате

Подскажите, есть нормальный способ в python получать данные запроса не одним огромным списком, а вычитывать потоково? Есть хоть одна библиотека, умеющая это?

может при чтении преобразовывается дата к установленной таймзоне?

так и есть

Подскажите, есть нормальный способ в python получать данные запроса не одним огромным списком, а вычитывать потоково? Есть хоть одна библиотека, умеющая это?

Http запрос и декодировать стрим?

так и есть

нужно поставить зону в клиенте, которым читаете

Http запрос и декодировать стрим?

То есть "нет, пиши сам"?

нужно поставить зону в клиенте, которым читаете

использую Datagrip, но в нем какие то траблы с настройкой таймзоны

То есть "нет, пиши сам"?

скорее это один из вариантов )

использую Datagrip, но в нем какие то траблы с настройкой таймзоны

а можете рассказать, как вы датагрип прикрутили?

я пробовал jdbc драйвер, но он эксепшенами кидался, ничего не вышло