The reasons and advantages of the third Baihuist way of using SQLite in Node.js

    The bearers of Zen Python believe that there should be one (and, preferably, only one) obvious way to achieve the desired.

    And those who comprehend the list of Node.js modules can be convinced that the creators of these modules are spiritually closer not to Zen Buddhists, but to Baihuists - to fans of the Baihua Undong movement (百花 Ма), proclaimed by Mao Zedong in 1957 based on classic Chinese poems “let a hundred flowers bloom, let a hundred schools compete”, beginning with the words “bai hua” (“百花”, “hundred flowers”). In other words, modules for Node.js provide, as a rule, severalways to do the same thing, and from them the consumer chooses the method that is most suitable for him.

    But why is there no one way that would be suitable for everyone?

    I propose to consider the answer to this question using an example of using a SQLite database.

    The engine Node.js (unlike, for example, from JSDB ) is unpowered means to access SQLite bases, providing its implementation module side. The most popular of these is the sqlite3 module , supported by the well-known mapping company MapBox . It has, according to npm statistics , tens of thousands of downloads per month.

    Looking at him intently, it is easy to see that the code of this popular module is not entirely javascript. It is based on connecting the source (sishnogo) code SQLite as compiled additions (addon) for Node. This is not the reason for the module’s wide suitability: for Linux and Mac OS X, tools for building programs are abundant, but for Windows the need to satisfy the requirements of node-gyp is sometimes very painful. A special problem is the 64-bit version of Windows, which requires not only Microsoft Visual Studio C ++ 2010 to build add-ons(the free Express version is also suitable), but also the weighty Windows 7 64-bit SDK, the ISO image of which occupies more than 570 megabytes.

    In response to this inconvenience, a second way of using SQLite in Node appeared - the node-sqlite-purejs module , whose code does not require assembly, because it consists (which is reflected in the module name) of pure javascript executed directly by the Node engine. This code is based on the SQL.js script that Alon Zakai (creator of Emscripten) received by passing SQLite code through Emscripten - I mentioned this achievement on Habrahabr in March last (2012).

    Unfortunately, the lack of C code is almost the only advantage of this module: it expects to wish much better in terms of stability, and the list of unresolved problems includes data loss and the impossibility of soft shutdown. All this is because in the process of automatic translation from C JavaScript code was apparently lost an atomic transaction, SQLite is the main useful property. Until this problem is solved, we can sadly consider this second method to be a dead end.

    More recently (last week on Sunday - October 27) it became possible to read in the nodejs google groupabout the emergence of a third way to use SQLite in Node, devoid of the main disadvantages of both of its predecessors. This new module ( opendatabase ) does not contain SQLite code in either javascript or even javascript form - instead, it calls the sqlite program (called sqlite.exe on Windows ) through the good old command line interface, dumping SQL queries into it and parsing it with javascript her response.

    It is easy to guess that this module will not require tools for compilation and assembly (which the mapbox module sqlite3 needed): just download the sqlite programfrom the SQLite site in a finished form. For the same reason, there will be no problems with imperfect implementations ( observed in node-sqlite-purejs ): the downloaded program contains an official implementation.

    That is why in this module I see the triumph of the Baihuist principle of diversity and co-prosperity, once again confirming the correctness of the Chinese dictum ibu ibudi- huydao mudi (“一步 一步 地 会 到 目的”, “step by step you can achieve the goal”).

    To this third module I can reproach only the location of its source on Bitbucketand in Mercurial (and not on Github and Git, like most other Node modules), which is unusual for me (which means that it will make it difficult to familiarize yourself with the guts and capabilities of the module, it will make it difficult to keep track of its further development). Other programmers (more familiar with Bitbucket and Mercurial) probably will not find this shortcoming significant (but when looking at the source they will find, perhaps, other shortcomings that I still don’t know). I have not yet read the source code of this module, so here my story ends.

    Also popular now: