Привет всем! Кто-то пользовался настройкой target-blacklist graphite-clickhouse ?

Можно ли с ее помощью скрыть саму метрику из поиска?

ClickHouse Meetup в Санкт-Петербурге: https://events.yandex.ru/events/ClickHouse/16-aug-2018/ Открываем регистрацию.

Добрый день! Зарегистрировался на мероприятие. Должно ли прийти подтверждение?

Добрый день! Зарегистрировался на мероприятие. Должно ли прийти подтверждение?

Я недели две ждал апрува, иногда в самый последний день апрув прилетает.

Я недели две ждал апрува, иногда в самый последний день апрув прилетает.

печально. Надо как-то на работе порешать вопрос с отсутствием (я не из Питера), а времени уже остается мало

Я сам с Питера и вот в Москву так ездил ) 50% на 50%. Апрув пришел за день до митапа, но в компании были наготове покупать билеты и согласовали командировку.

В той же ситуации, только из Мск ) Очень хотелось бы получить комментарии от сотрудников Яндекса

больше вопросов было только в анкете jug.ru для людей которые потратили по 50к чтобы получить свое видео

А нет вариантов как в Табиксе сделать окошко результа во внешнем окошке?

Коллеги, добрый день! А у кого-то удавалось подключить внешний словарь в виде api через http? Я прописал все конфиги, есть api, которая возвращает json. Делаю запрос к словарю и в итоге возвращается ошибка вида: Code: 27. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Cannot parse input: expected { before: [{"publisher_id": 999, "id": 1}, {"publisher_id": 5, "id": 2}, {"publisher_id": 756, "id": 3}]: (at row 1) Т.е. КХ видит api, получает из неё данные, но не может переварить результат. Я конфигах указывал и JSON и JSONEachRow. Ничего не помогает.

Коллеги, добрый день! А у кого-то удавалось подключить внешний словарь в виде api через http? Я прописал все конфиги, есть api, которая возвращает json. Делаю запрос к словарю и в итоге возвращается ошибка вида: Code: 27. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Cannot parse input: expected { before: [{"publisher_id": 999, "id": 1}, {"publisher_id": 5, "id": 2}, {"publisher_id": 756, "id": 3}]: (at row 1) Т.е. КХ видит api, получает из неё данные, но не может переварить результат. Я конфигах указывал и JSON и JSONEachRow. Ничего не помогает.

1) то что видно - это не JSONEachRow точно 2) дайте весь ответ от API и конфиг словаря

Запрос: select dictGetString('positions_publishers', 'publisher_id', toUInt64(2)) Ответ: Received exception from server (version 1.1.54370): Code: 85. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Format JSON is not suitable for input. Конфиг: <dictionary> <name>positions_publishers</name> <source> <http> <url>http://localhost:8000/campaigns/api/clickhouse/get_publishers</url> <format>JSON</format> </http> </source> <layout> <flat/> </layout> <lifetime> <min>3</min> <max>7</max> </lifetime> <structure> <id> <name>id</name> </id> <attribute> <name>publisher_id</name> <type>String</type> <null_value>0</null_value> </attribute> </structure> </dictionary>

Запрос: select dictGetString('positions_publishers', 'publisher_id', toUInt64(2)) Ответ: Received exception from server (version 1.1.54370): Code: 85. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Format JSON is not suitable for input. Конфиг: <dictionary> <name>positions_publishers</name> <source> <http> <url>http://localhost:8000/campaigns/api/clickhouse/get_publishers</url> <format>JSON</format> </http> </source> <layout> <flat/> </layout> <lifetime> <min>3</min> <max>7</max> </lifetime> <structure> <id> <name>id</name> </id> <attribute> <name>publisher_id</name> <type>String</type> <null_value>0</null_value> </attribute> </structure> </dictionary>

Как минимум publisher_id у вас не String

Как минимум publisher_id у вас не String

Об это я споткнулся, когда подключал другой словарь из Postgres через ODBC. В источнике id'шник типа integer, ну и логично было указать в конфиге Int32. Прописал, сохранил, делаю запрос - ошибка на какое-то нессответствие типов. Пробовал разные варианты для этого атрибута: (U)Int16, (U)Int32, (U)Int64. Всё время была ошибка. Помогло только String. Хотя в источнике этот атрибут с типом integer.

Об это я споткнулся, когда подключал другой словарь из Postgres через ODBC. В источнике id'шник типа integer, ну и логично было указать в конфиге Int32. Прописал, сохранил, делаю запрос - ошибка на какое-то нессответствие типов. Пробовал разные варианты для этого атрибута: (U)Int16, (U)Int32, (U)Int64. Всё время была ошибка. Помогло только String. Хотя в источнике этот атрибут с типом integer.

DB::Exception: Format JSON is not suitable for input.

вам сервер намекает

что format JSON нельзя использовать для input

https://clickhouse.yandex/docs/ru/interfaces/formats/

что format JSON нельзя использовать для input

ммм, так стало быть, КХ не сможет прочитать данные из API?

может, если API отдает данные в формате JSONEachRow

Cannot parse input: expected { before: [{"publisher_id": 999, "id": 1}, {"publisher_id": 5, "id": 2}, {"publisher_id": 756, "id": 3}]: (at row 1)

не должно быть [ вначале

и разделителем данных должен быть перенос строки

странные ограничения

да и вообще нет смысла отдавать весь массив, нужно отдавать один запрашиваемый элемент по ключу POST запроса

select dictGetString('positions_publishers', 'publisher_id', toUInt64(2)) -> {"publisher_id": 5, "id": 2}

да и вообще нет смысла отдавать весь массив, нужно отдавать один запрашиваемый элемент по ключу POST запроса

В идеале хотелось бы весь словарь хранить в памяти (layout - flat). При схеме "один запрос к словарю"-"одно обращение к api", если я правильно понимаю, будет много ненужного обращения к api. Т.е. при вставке миллионов строк для обогащения атрибутом publisher_id будут сделаны миллионы запросов к api. Зачем, ведь словарь же можно и памяти хранить.

В идеале хотелось бы весь словарь хранить в памяти (layout - flat). При схеме "один запрос к словарю"-"одно обращение к api", если я правильно понимаю, будет много ненужного обращения к api. Т.е. при вставке миллионов строк для обогащения атрибутом publisher_id будут сделаны миллионы запросов к api. Зачем, ведь словарь же можно и памяти хранить.

да, лучше все держать в памяти, если данных не сильно много то это вполне терпимо

извините, не обратил внимание что у вас flat. Да, тогда есть смысл весь массив отдать

он массив должен быть в одном из допустимых для input форматов

В общем, не получилось. Придётся брать данные по ODBC из самой postgres. Буду признателен, если кто-нибудь поделется своим решением по поводу api и json.

а что конкретно не получилось?

Победить сообщение "Cannot parse input: expected { before:" при обращении к словарю. Дальше после этого сообщения идёт содержимое ответа api, вот ведь оно, дошло сообщение api. Но я не понимаю почему КХ не может разобрать ответ.

Победить сообщение "Cannot parse input: expected { before:" при обращении к словарю. Дальше после этого сообщения идёт содержимое ответа api, вот ведь оно, дошло сообщение api. Но я не понимаю почему КХ не может разобрать ответ.

Эта ошибка возникает при обращении к словарю или при релоаде словаря?

При обращении.

Всем привет! Прошу помощи! Code: 47, e.displayText() = DB::Exception: Unknown identifier: createdAt, e.what() = DB::Exception При SELECT * FROM coupons WHERE (couponCode = '0200000001') ORDER BY createdAt DESC FORMAT JSON запрос кидаю черех smi2/phpClickHouse Ошибка вылетает раз в 1-3 запроса, остальные отрабатывают норм, реплик нету, в чём проблема может быть?

говорит, что столбца createdAt нет в результате

точнее, в таблице coupons

Да, но он есть

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

Ну, оно раз в 3 запроса падает, я думаю оно бы тогда падало постоянно

Чекнул всё, всеравно падает иногда, через нативный клиент работает всё, через табикс тоже работает, а вот если с пыхи кидать - падает раз в 3

$client->verbose(); вам в помошь, можно попробовать просто через консольный curl

Чекнул всё, всеравно падает иногда, через нативный клиент работает всё, через табикс тоже работает, а вот если с пыхи кидать - падает раз в 3

похоже, придётся дебажить пхп клиент

Запросы он кидает одинаковые всегда, дебажил, вот сам сервак возвращает разные ответы всегда

Просто это странно, раз в 2-3 запроса падает, остальные норм отдаёт

if (source.agent==php) suffer();

if (source.agent==php) suffer();

Было бы смешно, если бы не было так грустно)))

@milovidov_an Алексей, подскажите, в настройке словарей через odbc в версиях 18.1.хх что-то менялось? После обновления перестали работать словари - не может найти датасорс. Откатили на 1.1.54394 - все опять заработало

При обращении.

Видимо API все таки возвращает JSON, а не JSONEachRow. Мы у себя добились JSONEachRow с помощью реализации кастомного форматтера для ответа из API. Если ваш API возвращает все таки JSONEachRow - попробуйте сделать RELOAD словаря и посмотреть в системной таблице словарей последнюю ошибку.

При обращении.

Ну и в конфигурации словаря соответственно надо проверить, что указан формат JSONEachRow

Доброго дня всем! Возникла ситуация: кончилось место на диске. Этот факт был отмечен в логах clickhouse, в то время, как он сам перестал отвечать на попытки подключиться к нему. Потом место мы освободили, сервер перезапустили, но clickhouse все равно на попытки подключиться отвечает: ClickHouse client version 1.1.54236. Connecting to localhost:9000. Code: 210. DB::NetException: Connection refused: (localhost:9000, ::1) В чем может быть проблема?

вроде логичнее было бы просто json сделать

Было бы смешно, если бы не было так грустно)))

Проверьте DNS - что IP всегда сервера, и что database('name') - всегда указан, может есть еще база с такой таблицей SELECT * FROM coupons.coupons WHERE (couponCode = '0200000001') ORDER BY createdAt И самый простой вариант - это через простой Curl подергать CH без PHP

Доброго дня всем! Возникла ситуация: кончилось место на диске. Этот факт был отмечен в логах clickhouse, в то время, как он сам перестал отвечать на попытки подключиться к нему. Потом место мы освободили, сервер перезапустили, но clickhouse все равно на попытки подключиться отвечает: ClickHouse client version 1.1.54236. Connecting to localhost:9000. Code: 210. DB::NetException: Connection refused: (localhost:9000, ::1) В чем может быть проблема?

Смотрите что КХ пишет в логах, возможно он ещё не стартанул

Видимо API все таки возвращает JSON, а не JSONEachRow. Мы у себя добились JSONEachRow с помощью реализации кастомного форматтера для ответа из API. Если ваш API возвращает все таки JSONEachRow - попробуйте сделать RELOAD словаря и посмотреть в системной таблице словарей последнюю ошибку.

Мне удалось буквально только что сделать так, что бы КХ понимал простой json. Т.е. API отдаёт {'publisher_id': '999', 'id': '1'} и запрос SELECT dictGetString('positions_publishers', 'publisher_id', toUInt64(1)) отрабатывает без ошибки и возвращает 999. А если на стороне api формирую список словарей (python) и отдаю, то опять возникает ошибка "Cannot parse input: expected { before: ...". Т.е., видимо, что-то на стороне api при конвертировании питоновского списка словарей не так.

Я там ничего подозрительного не увидел

Мне удалось буквально только что сделать так, что бы КХ понимал простой json. Т.е. API отдаёт {'publisher_id': '999', 'id': '1'} и запрос SELECT dictGetString('positions_publishers', 'publisher_id', toUInt64(1)) отрабатывает без ошибки и возвращает 999. А если на стороне api формирую список словарей (python) и отдаю, то опять возникает ошибка "Cannot parse input: expected { before: ...". Т.е., видимо, что-то на стороне api при конвертировании питоновского списка словарей не так.

Попробуйте через Postman обратиться к своему API и посмотреть какие данные возвращаются. Если это список объектов, типа: [{...}, {...}, ...], то в этом и есть проблема, т.к. с этим форматом Clickhouse не работает. Надо избавляться от [] и использовать разделитель перенос строки, вместо запятой.

Мне удалось буквально только что сделать так, что бы КХ понимал простой json. Т.е. API отдаёт {'publisher_id': '999', 'id': '1'} и запрос SELECT dictGetString('positions_publishers', 'publisher_id', toUInt64(1)) отрабатывает без ошибки и возвращает 999. А если на стороне api формирую список словарей (python) и отдаю, то опять возникает ошибка "Cannot parse input: expected { before: ...". Т.е., видимо, что-то на стороне api при конвертировании питоновского списка словарей не так.

используйте TSV или CSV вместо json

select 999 publisher_id, 1 id union all select 5 publisher_id, 2 id union all select 756 publisher_id, 3 id format JSONEachRow вот что ожидает КХ {"publisher_id":999,"id":1} {"publisher_id":756,"id":3} {"publisher_id":5,"id":2}

Обычный json слишком медленный для парсинга, видимо разработчики тратить время на него не хотят.

Получилось!

Ребят, а не было какой нить инструкции пошаговой, как dictionary подключить через odbc. Например файл с описанием внешнего словаря надо создать это я понял, а котом его где нибудь надо в config.xml прописывать? или он и так поймет?

то что сейчас есть https://clickhouse.yandex/docs/ru/operations/table_engines/dictionary/, не очевидно имхо. Я бы внес изменения даже как PR, но хотя бы понять куда копать.

Ребят, а не было какой нить инструкции пошаговой, как dictionary подключить через odbc. Например файл с описанием внешнего словаря надо создать это я понял, а котом его где нибудь надо в config.xml прописывать? или он и так поймет?

Сейчас вышлю

Мой api в итоге отправляет такой ответ b'[{"publisher_id": "999", "id": "1"}, {"publisher_id": "5", "id": "2"}, {"publisher_id": "756", "id": "3"}]'

Надо было просто убрать квадратные скобки

Сейчас вышлю

Спасибо!

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

Проверьте DNS - что IP всегда сервера, и что database('name') - всегда указан, может есть еще база с такой таблицей SELECT * FROM coupons.coupons WHERE (couponCode = '0200000001') ORDER BY createdAt И самый простой вариант - это через простой Curl подергать CH без PHP

Прочекал всё, попробовал всё дропнуть и заново создать, теперь Code: 49, e.displayText() = DB::Exception: Could not find a column of minimum size in MergeTree, part /var/lib/clickhouse/data/coupon/coupons/20180803_20180803_1_6_1/, e.what() = DB::Exception

Может знает кто в чём дело?

Привет. После обновления кластера до актуальной версии на одной из реплик появилась проблема с мерджем очень старых данных. Мердж идет, в итоге возникает ошибка - и он повторяется заново, в цикле. Почему-то с другой реплики этот part не скачивается. На второй реплике этого шарда никаких проблем нет. 2018.08.03 16:56:02.583570 [ 12 ] <Error> SrcData.TTStatBase (StorageReplicatedMergeTree): Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: hash of uncompressed files doesn't match, uncompressed hash of compressed files doesn't match, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result. Вот выдержка из лога по этому треду. 2018.08.03 16:56:02.352540 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Merge sorted 118552713 rows, containing 166 columns (6 merged, 160 gathered) in 234.24 sec., 506113.87 rows/sec., 649.20 MB/sec. 2018.08.03 16:56:02.356438 [ 12 ] <Trace> SrcData.TTStatBase (Data): Renaming temporary part tmp_merge_201709_63076_64611_5 to 201709_63076_64611_5. 2018.08.03 16:56:02.356510 [ 12 ] <Trace> SrcData.TTStatBase (MergerMutator): Merged 3 parts: from 201709_63076_63675_4 to 201709_64197_64611_4 2018.08.03 16:56:02.583501 [ 12 ] <Debug> SrcData.TTStatBase (Data): Undoing transaction. Removing parts: 201709_63076_64611_5. 2018.08.03 16:56:02.583570 [ 12 ] <Error> SrcData.TTStatBase (StorageReplicatedMergeTree): Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: hash of uncompressed files doesn't match, uncompressed hash of compressed files doesn't match, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result. 2018.08.03 16:56:02.583670 [ 12 ] <Debug> MemoryTracker: Peak memory usage: 39.87 MiB. 2018.08.03 16:56:02.753503 [ 12 ] <Debug> SrcData.TTStatBase (StorageReplicatedMergeTree): Part 201709_63076_64611_5 (state Outdated) should be deleted after previous attempt before fetch 2018.08.03 16:56:02.753556 [ 12 ] <Trace> SrcData.TTStatBase (StorageReplicatedMergeTree): Executing log entry to merge parts 201709_63076_63675_4, 201709_63676_64196_4, 201709_64197_64611_4 to 201709_63076_64611_5 2018.08.03 16:56:02.753587 [ 22 ] <Trace> SrcData.TTStatBase (Data): Found 1 old parts to remove. 2018.08.03 16:56:02.753614 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Merging 3 parts: from 201709_63076_63675_4 to 201709_64197_64611_4 into tmp_merge_201709_63076_64611_5 2018.08.03 16:56:02.753622 [ 22 ] <Debug> SrcData.TTStatBase (StorageReplicatedMergeTree): Removing 1 old parts from ZooKeeper 2018.08.03 16:56:02.755014 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Selected MergeAlgorithm: Vertical 2018.08.03 16:56:02.755235 [ 12 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 201709_63076_63675_4, approx. 46530560 rows starting from 0

2018.08.03 16:56:02.755405 [ 12 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 201709_63676_64196_4, approx. 40615936 rows starting from 0 2018.08.03 16:56:02.755483 [ 12 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 201709_64197_64611_4, approx. 31416320 rows starting from 0

Может знает кто в чём дело?

Seems like the problem was 2 instances of clickhouse-server running at the same time. Not sure how I got to this scenario... https://groups.google.com/forum/#!topic/clickhouse/chYoOYgcxoQ тут чате тоже есть про Could not find a column of minimum size

Привет. После обновления кластера до актуальной версии на одной из реплик появилась проблема с мерджем очень старых данных. Мердж идет, в итоге возникает ошибка - и он повторяется заново, в цикле. Почему-то с другой реплики этот part не скачивается. На второй реплике этого шарда никаких проблем нет. 2018.08.03 16:56:02.583570 [ 12 ] <Error> SrcData.TTStatBase (StorageReplicatedMergeTree): Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: hash of uncompressed files doesn't match, uncompressed hash of compressed files doesn't match, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result. Вот выдержка из лога по этому треду. 2018.08.03 16:56:02.352540 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Merge sorted 118552713 rows, containing 166 columns (6 merged, 160 gathered) in 234.24 sec., 506113.87 rows/sec., 649.20 MB/sec. 2018.08.03 16:56:02.356438 [ 12 ] <Trace> SrcData.TTStatBase (Data): Renaming temporary part tmp_merge_201709_63076_64611_5 to 201709_63076_64611_5. 2018.08.03 16:56:02.356510 [ 12 ] <Trace> SrcData.TTStatBase (MergerMutator): Merged 3 parts: from 201709_63076_63675_4 to 201709_64197_64611_4 2018.08.03 16:56:02.583501 [ 12 ] <Debug> SrcData.TTStatBase (Data): Undoing transaction. Removing parts: 201709_63076_64611_5. 2018.08.03 16:56:02.583570 [ 12 ] <Error> SrcData.TTStatBase (StorageReplicatedMergeTree): Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: hash of uncompressed files doesn't match, uncompressed hash of compressed files doesn't match, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result. 2018.08.03 16:56:02.583670 [ 12 ] <Debug> MemoryTracker: Peak memory usage: 39.87 MiB. 2018.08.03 16:56:02.753503 [ 12 ] <Debug> SrcData.TTStatBase (StorageReplicatedMergeTree): Part 201709_63076_64611_5 (state Outdated) should be deleted after previous attempt before fetch 2018.08.03 16:56:02.753556 [ 12 ] <Trace> SrcData.TTStatBase (StorageReplicatedMergeTree): Executing log entry to merge parts 201709_63076_63675_4, 201709_63676_64196_4, 201709_64197_64611_4 to 201709_63076_64611_5 2018.08.03 16:56:02.753587 [ 22 ] <Trace> SrcData.TTStatBase (Data): Found 1 old parts to remove. 2018.08.03 16:56:02.753614 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Merging 3 parts: from 201709_63076_63675_4 to 201709_64197_64611_4 into tmp_merge_201709_63076_64611_5 2018.08.03 16:56:02.753622 [ 22 ] <Debug> SrcData.TTStatBase (StorageReplicatedMergeTree): Removing 1 old parts from ZooKeeper 2018.08.03 16:56:02.755014 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Selected MergeAlgorithm: Vertical 2018.08.03 16:56:02.755235 [ 12 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 201709_63076_63675_4, approx. 46530560 rows starting from 0

Что с этим можно сделать? Рестарт CH не помогает. Версии CH на репликах сейчас идентичны, но в процессе апдейта некоторое время были разными, конечно.

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

Спасибо. Да, тут гораздо больше надо действий чем написано в доке.

Добрый день! Зарегистрировался на мероприятие. Должно ли прийти подтверждение?

Подтверждения присылаются не сразу, а периодически - сразу пачкой.

Подтверждения присылаются не сразу, а периодически - сразу пачкой.

а в течение какого периода можно ожидать?

@milovidov_an Алексей, подскажите, в настройке словарей через odbc в версиях 18.1.хх что-то менялось? После обновления перестали работать словари - не может найти датасорс. Откатили на 1.1.54394 - все опять заработало

Да, в 18.6.0 попали изменения с фильтрацией connection string. Поставьте пока 18.5.1.

а в течение какого периода можно ожидать?

До 15 августа.

До 15 августа.

спасибо

Evgeny Vinogradov (0) увеличил репутацию Alexey Milovidov (1)

Да, в 18.6.0 попали изменения с фильтрацией connection string. Поставьте пока 18.5.1.

спасибо

Dmitry Nagovitsin (0) увеличил репутацию Alexey Milovidov (2)

Кто-нибудь использует alias для JOIN?

При этом если указать так SELECT *, d.*, d.values Тогда d.values вернёт то что нужно. Выглядит как баг

а есть ли возможность сохранить метаданные таблицы, например, версию схемы, чтобы сделать какие-то миграции?

При этом если указать так SELECT *, d.*, d.values Тогда d.values вернёт то что нужно. Выглядит как баг

Звездочка будет переделываться, сейчас работает странно в джойнах... пока лучше явно указывать нужные колонки

Просто совсем недавно, условно месяц назад, такого поведения не было

Не может быть)