Причины и достоинства третьего байхуистского способа употребления SQLite в Node.js

    Постигшие дзэн Пайтона считают, что должен быть один (и, желательно, только один) очевидный способ достигнуть желаемого.

    А постигшие список модулей Node.js могут убедиться в том, что создатели этих модулей духовно ближе не к дзэн-буддистам, а к байхуистам к поклонникам движения «Байхуа юньдун» (百花运动), провозглашённого Мао Цзэдуном в 1957 году по мотивам классического китайского стихотворения «пусть расцветают сто цветов, пусть соперничают сто школ», начинающегося словами «бай хуа» («百花», «сто цветов»). Иными словами, модули для Node.js предоставляют, как правило, несколько способов сделать одно и то же, и из них потребитель выбирает тот способ, который более всех пригоден ему.

    Но почему не существует такого одного способа, который был бы пригоден для всех?

    Ответ на этот вопрос я предлагаю рассмотреть на примере употребления базы данных SQLite.

    Движок Node.js (в отличие, например, от JSDB) не имеет встроенного средства для доступа к базам SQLite, предоставляя его реализацию сторонним модулям. Наиболее популярным из них является модуль sqlite3, поддерживаемый известной картографической компанией MapBox. Он насчитывает, по статистике npm, десятки тысяч скачиваний в месяц.

    Сколько-нибудь пристально приглядевшись к нему, нетрудно заметить, что код этого популярного модуля не целиком является джаваскриптовым. Он основан на подключении исходного (сишного) кода SQLite в качестве компилируемого дополнения (addon) для Node. Это-то и является причиною не сáмой широкой пригодности модуля: под Linux и под Mac OS X средства сборки программ имеются в изобилии, а вот для Windows необходимость удовлетворить требованиям node-gyp подчас бывает весьма тягостною. Особенную проблему представляет собою 64-разрядная версия Windows, на которой для сборки дополнений понадобится не только Microsoft Visual Studio C++ 2010 (годится и бесплатная Express-версия), но также и увесистый Windows 7 64-bit SDK, ISO-образ которого занимает более 570 мегабайтов.

    В ответ на это неудобство появился второй способ употребления SQLite в Node — модуль node-sqlite-purejs, код которого не требует сборки, потому что он состоит (что отражено и в названии модуля) из чистого джаваскрипта, исполняемого движком Node непосредственно. Этот код основан на скрипте SQL.js, который Alon Zakai (создатель Emscripten) получил, пропустив код SQLite через Emscripten — об этом его достижении я упоминал на Хабрахабре в марте прошлого (2012) года.

    К сожалению, отсутствие кода на Си является чуть ли не единственным преимуществом этого модуля: он ожидает желать много лучшего в отношении стабильности работы, и в списке ещё не решённых проблем его значится потеря данных и невозможность мягкого завершения работы. Всё это потому, что в процессе автоматического перевода с языка Си на JavaScript была, по-видимому, потеряна атомарность транзакций, являющаяся главнейшим полезным свойством SQLite. Пока эта проблема не решена, мы можем печально считать этот второй способ тупиковым.

    Совсем недавно (на прошлой неделе в воскресенье — 27 октября) в гуглогруппе «nodejs» стало можно прочесть о появлении третьего способа употребления SQLite в Node, лишённого основных недостатков обоих своих предшественников. Этот новый модуль (opendatabase) не содержит код SQLite ни в сишной, ни даже в джаваскриптовой форме — вместо этого он вызывает программу sqlite (в Windows называемую sqlite.exe) через старый добрый интерфейс командной строки, скидывая в неё SQL-запросы и джаваскриптом разбирая отклик её.

    Нетрудно догадаться, что этому модулю не потребуются средства для компиляции и сборки (которые мэпбоксовскому модулю sqlite3 требовалися): программу sqlite достаточно скачать с сайта SQLite в готовом виде. По той же причине не возникнет и проблем с неидеальностью реализации (в node-sqlite-purejs наблюдавшихся): скачанная программа содержит официальную реализацию.

    Вот почему в этом модуле я вижу обретённым торжество байхуистского принципа разнообразия и сопроцветания, в очередной раз подтверждающее правоту китайского изречения «ибу ибуди — хуйдао муди» («一步一步地会到目的», «шаг за шагом можно достигнуть цели»).

    Этому третьему модулю я пока могу поставить в упрёк только расположение его исходников на Bitbucket и в Mercurial (а не на Гитхабе и в Git, как у большинства других модулей Node), что для меня не привычно (а значит, затруднит знакомство с потрохами и возможностями модуля, затруднит слежение за дальнейшим развитием его). Другие же программисты (более с Bitbucket и Mercurial знакомые) наверняка не сочтут этот недостаток существенным (зато при вглядывании в исходники найдут там, быть может, другие недостатки, мне ещё не известные). Я же пока ещё не читал исходный код этого модуля, так что здесь рассказ мой оканчивается.
    Share post

    Comments 10

      0
      Похоже, что на Хабрахабре нет хаба SQLite.

      Мне пришлось поместить блогозапись в более общем хабе SQL поэтому.
        +1
        A propos: «пусть расцветают сто цветов, пусть соперничают сто школ» — это была прелюдия к «пусть змея высунет голову» господина Цинь Шихуанди, а потом и товарища Мао. В обоих случаях дело кончилось головотяпством.
          +1
          Да, к сожалению.

          Но это употребление её не умаляет ценности основной идеи.
          –1
          Бай какого способа?
            0
            Скажите, а когда поклонников произведений Лавкрафта называют ктулхуистами, Вы примерно так же переспрашиваете?
              –1
              Ну а зачем использовать заведомо неблагозвучное словообразование.
              Что, суффиксов на свете мало? Обязательно нужно было заимствованный из латыни взять? Так ведь и в латыни есть варианты.
              Байхуанство, например, вместо байхуизма.

              P.S.
              Варенье из фейхоа — запомните, дети, — фейхОевое.
            +1
            Как я понимаю к проблемам третьего способа можно добавить низкую скорость работы из-за производительности такой реализации?
              0
              Да, потому что велики накладные расходы на создание внешнего процесса — более велики, чем обращение к функции кода внутри модуля.

              Можно, впрочем, развить подход этот: не завершать и не перезапускать программу sqlite, держать её в памяти беспрерывно, продолжать кормить её директивами через стандартный вход. Но всё равно обращение ко входу и выходу процесса обходится дороже, чем ко внутренней функции.
              +1
              Улыбнуло :) Хотя в продакшене сам SQLite вообще не интересен.
                +1
                sqlite интересен в таких вещах как node-webkit, зачастую и в продакшене

              Only users with full accounts can post comments. Log in, please.