DT
И кмк обернуть JSONEachRow в валидный массив Json довольно просто
Size: a a a
2020 August 22
DD
если данных много то не просто. вернее просто но будет 2-4х по памяти.
DT
Dmitriy D
если данных много то не просто. вернее просто но будет 2-4х по памяти.
кто мешает построчно-потоково обрабатывать?
DT
Dmitriy D
та ладно. уже даже постгрес умеет
Да, посмотрел, есть такой вариант:
SELECT json_agg((column1, column2, ...)) FROM t
Но мне он не особо нравится, имхо
SELECT json_agg((column1, column2, ...)) FROM t
Но мне он не особо нравится, имхо
DD
зачем вообще обрабатывать то что можно просто отдать? в этом то и смысл БД. я селектом выбрал все что нужно и мне нужно просто отдать это на юай. не надо ничего процесить
DD
кликхаус форсит меня делать этот процесинг потому что FORMAT JSON как-то непонятно зачем и для кого сделан
DT
Dmitriy D
кликхаус форсит меня делать этот процесинг потому что FORMAT JSON как-то непонятно зачем и для кого сделан
Ну мы отлично пользовались FORMAT JSON, когда не было нормального асинхронного драйвера для дотнета
DD
ну так и я пользуюсь. но я вынужден отдавать на юай поля "meta", "data", "statistics" которые никому не нужны
DD
а если обрезать эти поля на сервере перед отдачей то мне надо будет выделять память под все данные чтобы распарсить джейсон
DT
set output_format_write_statistics=0;
конкретно статистику можно отключить
конкретно статистику можно отключить
DD
да, знаю, но остаются другие поля
DT
Ну я думаю никто не будет против, если появится новый формат, как минимум feature request можешь сделать на эту тему
S
Dmitriy D
да, знаю, но остаются другие поля
дак в чем проблема с "другими полями"?
чем они вам так помешали?
вы ответ CH в какую то JS модель с валидацией засовываете? или что?
чем они вам так помешали?
вы ответ CH в какую то JS модель с валидацией засовываете? или что?
DD
ну, вот есть АПИ. АПИ юзают клиенты. клиент говорит, дай данные этого юзера, а вы ему отдаете джейсон и в этом джейсоне "meta", "data", "rows_count", "rows_count" которые его совершенно не интересуют. ему надо исключительно то что в "data"
S
Dmitriy D
ну, вот есть АПИ. АПИ юзают клиенты. клиент говорит, дай данные этого юзера, а вы ему отдаете джейсон и в этом джейсоне "meta", "data", "rows_count", "rows_count" которые его совершенно не интересуют. ему надо исключительно то что в "data"
ну и ? пусть возьмет что в data ;) что не так то?
DT
Ну для пагинации инфа в статистике бывает полезной(если там group_by есть)
DD
не, это усложнение для клиента, ему теперь надо парсить это поле, а если он хочет импортнуть куда-то, теперь ему надо это поле вырезать и тд, АПИ становится более говнистым. если вы понимаете о чем я.
DD
ну это один момент. второй момент - JSONEachRow - вообще не валидный джейсон отдает. это тоже ок?
DD
конечно можно обработать, и попросить клиентов не огорчаться, но блин. фича как бы есть, но ее и как бы нету.
DT
Dmitriy D
конечно можно обработать, и попросить клиентов не огорчаться, но блин. фича как бы есть, но ее и как бы нету.
Потому, что JSONEachRow используется для чтения из кафки к примеру, там каждое сообщение идет как отдельная сущность грубо говоря емнип