Не устанавливается mysql-libmysqlclient. Как исправить?

Как исправить?

Выкинуть эту кривизну.

какие-нибудь другие mysql-библиотеки для Node.js умеют в синхронные запросы?

Нет. Ставь `mysql`, оборачивай промисами с генераторами/co и не люби людям мозг. https://github.com/mysqljs/mysql/issues/929#issuecomment-60154347

Спс, уже так и сделал)

mysql

Во. Расскажи — почему не mysql2 (и не mariasql)?

У меня просто не было времени детально оценивать их надежность. Надо было дешево и сердито портануть vb-nntp с 0.6 ноды на четвертую. 40К/s запросов мне точно было не надо не надо, а в mysql я был уверен, фич хватало.

У mysql2 что-то меня в трекере смутило на тот момент. Но автор точно правильный чел. Поэтому если нужны какие-то фичи mysql2 - определенно стоит потратить время на вникание в детали.

mariasql не смотрел.

При выборе библиотек я смотрю на несколько вещей:

- удобство API
- проверенное временем API (количество и размеры проектов)
- поддержка
- качество кода
- отсутствие стрёмных тикетов в трекере

производительность учитывается только если критично и разница на порядок.

mysql подходил и требовал меньше всего времени на проверку. А с сиквелем я имею дело только в NNTP для воблы - не надо было учитывать перспективы в долгом проекте.

А где-то можно почитать сравнение mysql и mysql2 по критериям производительности, удобства и фичастости? Важность характеристик в порядке следования

Нигде. Читать ридми и смотреть код. По ридми апи обычно видно, подходит/нравится или нет.

На изучение производительности советую забить. В таких драйверах, с учетом авторов и времени, уже давно все сделано правильно, и даже не особо уступает сишечке. Даже если у тебя 1000 запросов в секунду, ты не заметишь может драйвер 20К или 40К слать.

Если ты не занимаешься чем-то с дикими нагрузками и вычислениями, для скорости достаточно не использовать ORM везде подряд. Вот там действительно можно скорость высадить.

Если ты не занимаешься чем-то с дикими нагрузками и вычислениями

Перманентно работающий парсер. Кидает все в базу. Нужно настолько быстро, насколько вообще возможно на ноде. Будет профит от mysql2?

не использовать ORM везде подряд

Вообще нигде не использую. Только чистый SQL

Перманентно работающий парсер. Кидает все в базу. Нужно настолько быстро, насколько вообще возможно на ноде. Будет профит от mysql2?

Смотря что парсер делает. Но обычно там CPU надо заметно больше чем для драйвера. Потому что объекты создаются. А драйвер в основном байтики перекладывает.

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

Если у тебя просто инсерты в табличку делаются, то все твои не существующие проблемы c драйвером решатся пакетированием - копишь 1000 записей и фигаришь в базу одним запросом. Profit.

Меня mysql слегка смущает в том числе тем, что они прямо в ридми в примерах приводят код, как отстрелить себе две ноги, и не пишут об этом. А пишут, что так и надо.

Где?

ХЗ. Под мои простые задачи все было пучком. Будешь пользоваться альтернативами - расскажи чего как.

Вот же: https://www.npmjs.com/package/mysql#escaping-query-values.

Они там начинают с того, что предлагают экранировать параметры ручками, и говорят, что это типа защита от SQLi.

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

Во, кстати. Я этой библиотекой не пользуюсь и мне несколько лень, но вот тикет: https://github.com/mysqljs/mysql/issues/1120.

Если хочешь, можешь им с этим помочь и накидать пулл реквест.

Нет смысла. Я не эскейплю ручками, и сиквель у меня только в легаси остался, который скоро кончится.

Ну это они долбонавты конечно, но первое что я проверял - что есть вариант автоэскейпинга. В конце концов, в тикете человек несколько раз попросил, чтобы заслали PR «как надо» вместо болтовни.

В конце концов, в тикете человек несколько раз попросил, чтобы заслали PR «как надо» вместо болтовни.

Да, Дуглас и так делает очень большую работу по поддержке кучи пакетов, которые изначально писали разные люди в разное время. Причём занимается этим в свободное время. Ему чуть-чуть не до этого.

Мне тоже этим заниматься не хочется, так как пакет mysql я не использую, а на вычитку-согласовывание правок понадобится некоторое время. Но написана там откровенная хрень, и кому-то надо это исправить.

Это лирика. Хрень в ридми на качество апи и кода не влияет. У кого пригорит по настоящему - исправит.

Не влияет напрямую, конечно, но этого и не надо — достаточно корреляции.

Кому и для чего достаточно? Мы не ломание софта вроде обсуждали.

Так. Ещё раз: я меньше верю в безопасность софта, который в ридми советует делать небезопасные вещи, по сравнению с софтом, который таким не страдает. Производить аудит пакета mysql мне тоже несколько лень.

С другой стороны — у более популярного есть преимущество в том, что его посмотрело больше человек. Но это работает нелинейно по очевидным причинам.

я меньше верю в безопасность софта, который в ридми советует

И при этом ты предлагал альтернативой mysql2, который имеет «полностью совместимое апи» (как у них написано). Где логика? Ты понимаешь, что надо оценивать не безопасность софта, а наличие безопасного апи для приложения?

И при этом ты предлагал альтернативой mysql2

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

Ты понимаешь, что надо оценивать не безопасность софта

Нихт.

Ну извини, с такими приоритетами по критериям спрашивать мое мнение бессмысленно, т.к. подобная система оценок мне не интересна.

а наличие безопасного апи для приложения

Это, кстати, не менее важно.

Я пытаюсь иногда прикладывать свои кривые руки к тому, чтобы небезопасного апи было меньше, а безопасного — больше.

Ну извини, с такими приоритетами по критериям спрашивать мое мнение бессмысленно, т.к. подобная система оценок мне не интересна.

Оки =).

На всякий случай — я немного сомневаюсь в адекватности (с точки зрения безопасности) людей, которые mysql написали изначально, и наличие у проекта такой хрени в документации — достаточно весомый флажок. По моему опыту с другими проектами, в том числе.

Это не имеет никакого отношения к Дугласу, конечно, он адекватен, он эту ересь там не писал, но на нём висит поддержка целой кучи всего.

Начали с того, как выбирались пакеты. Дык вот, я выбираю то, на чем можно удобно и безопасно писать код, и что легко поддерживать. Остальное - лирика. Как писать код криво меня не интересует.

Ты меня всё ещё не понял =).

Качество кода самой библиотеки зачастую коррелирует с такого рода косяками в документации.

Какой смысл рассуждать про идеальные шарообразные проекты, когда речь об одном вполне конкретном? Это не рациональная трата времени.

Кстати, вот тебе навскидку — пакет mysql не умеет в prepared statements. Вообще. Никак. В отличии от mysql2 =).

Больше того, вместо prepared statements он использует построение запроса экранированием и конкатенацией, но внутри себя.

Причём довольно внезапным для некоторых образом:

"SELECT * FROM user WHERE user = ? AND ?", ['a', {'foo.bar.baz': 1}]

SELECT * FROM user WHERE user = 'a' AND `foo`.`bar`.`baz` = 1

"SELECT * FROM user WHERE user = ?", [{a: 1, b: 2}]

SELECT * FROM user WHERE user = `a` = 1, `b` = 2

Ну плюс ещё можно заоверрайдить toString и получить то, что с виду выглядит как SQLi (но это в реальности не встретится, так как если ты позволяешь пользователю писать код toString — у тебя гораздо большие проблемы, чем SQLi).

Но это один фиг несколько не то, что ожидаешь от того, что выглдяит как prepared statements. Зарепортил: https://github.com/mysqljs/sqlstring/issues/6

Это не для всех ключевая фича. Например мне не надо.

Ну как хочешь. Да, забыл сказать — у них там уже были уязвимости, связанные с тем, что они ручками экранируют.

Апи от этого перестало быть безопасным и удобным? Они не фиксили ошибку годами после репорта? Ты опять скатываешься в технические детали, теряя общую картину. Это чисто хакерский подход - найти одну ошибку и забить на все остальное т.к. «задача по ломанию решена». Но при разработке, когда нужно не ломать а создавать, данный подход не продуктивен.

У меня недавно в pako (порт zlib на js) нашелся эпичный баг в deflate. После репорта ушел месяц до фикса, т.к. в итоге пришлось отрывать программиста от основного проекта. Но никто не рвал фуфайки и не хлопал дверью. Потому что знали, что проблема не провиснет и будет решена.

Ты опять скатываешься в технические детали, теряя общую картину. Это чисто хакерский подход - найти одну ошибку и забить на все остальное т.к. «задача по ломанию решена»

Ты, видимо, что-то не так понимаешь. Причём многое чего. Можно занудствовать и начать с термина «хакер», но я лучше на другое укажу: нет, типичный подход — произвести анализ, найти список уязвимостей, дальше собрать все возможные инстансы каждой. Но это к сути не относится, просто «типично» — именно это, а не то, что ты сказал.

К сути тут относится только одна вещь — как я оцениваю потенциальные проблемы безопасности от использования библиотеки по сравнению с альтернативами. Не «какая из них ломается». Не «в какой были дыры 100 лет назад». А оценка потенциальных проблем в будущем, причём сравнительная. Всё остальное — детали.

И несмотря на то, что у mysql есть некоторое преимущество за счёт массовости, у него есть несколько тревожных флажков (да, беглый осмотр нашёл уже несколько), указывающих на то, что он менее аккуратно сделан и в целом менее надёжен.

IMHO то что важно для моих проектов, я понимаю правильно :) . Внутренняя имплементация mysql полностью изолирована через API от внешнего приложения. Ее изменения и улучшения ничего снаружи не заденут. А вот если драйвер будет глючить, как mysql-libmysqlclient, то от рассуждений что у него потроха красивые никому легче не станет.

Для разработки важна не оценка проблем безопасности, а оценка стоимости решения проблем с пакетом. Причем всех проблем, а не только безопасности.

Внутренняя имплементация mysql полностью изолирована через API от внешнего приложения. Ее изменения и улучшения ничего снаружи не заденут.

Причём тут это, извиняюсь? Оно не полностью изолировано, пользователи в формочки данные шлют, они попадают внутрь запросов, всё такое. Так что если оно сломается — снаружи это именно что будет очень даже заметно. Если бы оно вообще никак ни на что не влияло — его можно было бы выкинуть.

Для разработки важна не оценка проблем безопасности, а оценка стоимости решения проблем с пакетом. Причем всех проблем, а не только безопасности.

Я пока что не услышал про какие-либо другие проблемы =). Ты же сам сказал, что API совместим, пока что мы рассматриваем ситуацию «при прочих равных».

Оно не полностью изолировано

Оно изолировано на уровне архитектуры и data flow. При помощи хорошего и стабильного API. И когда идет речь о проектировании (выборе библиотек), эти критерии работают, и дают что-то конструктивное, в отличие от рассуждений про код на низком уровне.

Я пока что не услышал про какие-либо другие проблемы =)

IMHO грамотный подход к проектированию заключается в том, чтобы не создавать проблем, а не в том чтобы их героически превозмогать. Мне не понравились какие-то тикеты, уже не помню какие, возможно их закрыли. А то проблемы бывают серьезные - уже было с mysql-libmysqlclient, где доходило до потерь коннектов, и автореконнект надо было костылять с неимоверными усилиями.