из коробки у он у меня вообще не завёлся, не отработал даже пример из README. не заработала также авторизация (там в хедере : не должно быть после Basic). не исключаю, что что-то не так делал, либо взял библиотеку не из правильного места.

RowBinary это формат кодирования данных
А сами запросы всё равно текстом отсылаются

Так вот в pillar это последовательный String.replace

А это значит, что это не только инъекция, а ещё и переполнение памяти может быть

Надо завести issue
Какие версии clickhouse и clickhousex?

@ar1ka1 @fried_zucchini

Там же экранирование параметров, а не вот это вот все) (Думаю, инъекцию сделать не получится)

По поводу String.replace не совсем понимаю, в чем проблема? Тут все пишут проекты без String.replace, а кто пишет - в зоне риска?

Там String.replace(query, "{#{param_name}}", value), что антиэффективно (потому что перекопирует строку кучу раз) и небезопасно. Из экранирования там только эскейпинг одинарных кавычек

Лучше всего распарсить в iodata или использовать какой-нибудь готовый язык темплейтов, умеющий заменять сразу всё.

Я не про то что String.replace это обязательно зло, а про то, что зачем делать себе больно на пустом месте изобретая свой собственный язык темплейтов и своё собственное экранирование?

Из того что я вижу уже сейчас, так это то, что темплейт резолвится в reduce-е, фигурные скобки не экранируются

И можно передавать %{a00: "(SELECT {primary} from table)", primary: "id"}
Что вернёт все id из какой-то там таблицы. Можно таким образом даже запрос запринтить

звучит как идея для импрувмента :)

я бы не сказал, что испытываю какую-либо боль, я бы испытал больше боли, если бы в таких мелочах заморачивался, но за пояснение спасибо :)

Лучше просто помочь допилить clickhousex. У него уже есть душный RowBinary

я уже помогал :) Пока с меня хватит, и так пару дней на это потратил)

Пока там тип запроса определяется регулярками (https://github.com/clickhouse-elixir/clickhousex/blob/8988b85f8ebc54614f4d983291a223501a69c78b/lib/clickhousex/query.ex#L30-L34) , мне в моей работе библиотека не подходит

Два разных инструмента для разных задач, в этом ничего плохого нет, один в одних задачах хорошо работает, другой в других

Пусть разными путями развиваются, конкуренция и все такое)

Два инструмента для одной и той же задачи. Определение типа запроса можно поправить, надо было завести issue

я сделал issue и добавил вам новую регулярку, которую приняли)

Конечно же я хотел бы поправить глобально, но это не так просто)

Задача может и одна, но возможности разные

Какие возможности?

Ну в пилларе вот что есть https://github.com/balance-platform/pillar#features
Pool of workers
Async insert
Buffer for periodical bulk inserts
Migrations

Мне критичная асинхронная булк вставка и миграции, например

> надо было завести issue

но если не хочется?:(

ну как бы да, про String.replace ведь тоже issue можно завести, а не антирекламу на весь чат делать :)

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

может, и лучше? откуда столько категоричности?

Да не работает clickhousex из коробки, не делал я бы свой, если бы не пришлось воевать с существующим, блин) и люди до сих про проблемы пишут, что не заводится

Пулл воркеров есть в clickhousex, потому что тот на db_connection
Асинхронный инзерт это какая-то плохая затея, но даже если так сильно хочется, что опять же, у clickhousex есть пулл и можно просто спавнить Task, и не ждать ответа
Буфферы это, по-моему, выше по уровню абстракции. И ничто тут не мешает дополнить clickhousex, если сильно хочется
А какие особенности у pillar с миграциями?

Миграции есть и фиксируются в самом кликхаусе, что подходит для систем, у которых из базы только кликхаус, без постгреса)