Unable to open DB read only about node-sqlite

[ajanian]

Ok. I got it to work.

I had to install sqlite3 as well. Shouldn't this be a dependency of sqlite? That wasn't very easy because it wouldn't install normally. After poking around I was able to get it to install via npm i [email protected] to avoid the 5.0.1 issue.

Once I did that I had to change my imports a bit - the naming seems to be off here with duplicates that don't all seem to work. My working code:

import { open } from 'sqlite';
import { getLogger } from 'log4js';
import sqlite3 from 'sqlite3';

const log = getLogger();
log.level = 'DEBUG';

// this is a top-level await 
(async (): Promise<void> => {
    log.debug("starting");

    try {
        // open the database
        const db = await open({
            filename: '/Users/andrewjanian/projects/nodethings/things3db.sqlite',
            driver: sqlite3.Database,
            mode: sqlite3.OPEN_READONLY
        });

        log.debug(db);

        const result = await db.all('SELECT * FROM TMArea');

        log.debug(result);

        for (const row of result) {
            log.debug(row);
        }
    } catch (err) {
        log.error(err);
    }

    log.debug("done");

})();

[theogravity]

For some history - v3 and prior used to include sqlite, but this was difficult to maintain because someone would have to bump up the version on it with each release. Not only that, it prevented people from using the alternative sqlite3-offline, which has precompiled binaries in situations where a complier isn't available or to reduce build times like in a CI system.

So for v4, we removed the direct dependency for it and now you specify the sqlite library you want to use. The decoupling allows for greater flexibility because you can now pick the library you want to use with it, and it can be at any reasonable version, and reduces less maintenance on our side because we now do not have to do package bumps for the libraries.

[theogravity]

I'm not sure what you mean by duplicates. From quick glance, the code looks ok

also what is the problem with 5.0.1? Usually a patch-level update shouldn't break any APIs

[ajanian]

@theogravity - not sure exactly what the problem is with 5.0.1 but on my mac I am not able to install 5.0.1 but I can install 5.0.0. Poking around there are others who have the same issue and that's where I got the idea to try pin 5.0.0

Regarding the duplication - duplication is probably not the right word. Before I had sqlite3 installed I was able to get OPEN_READONLY as a type definition from something called sqlite3 but there was a runtime error that sqlite3 couldn't be found. Similarly, Database (the driver) is defined in your code and also sqlite3 but fails silently if sqlite3 isn't installed. I think there are just some namespace overlaps that caused me confusion. Since I didn't have sqlite3 installed I would have assumed that I wouldn't be able to reference the types, etc.

[theogravity]

This is where having that flexibility come in - if this library had an explicit dependency for sqlite3, then it'd be hard for anyone to use the version they want, especially if they encounter issues with whatever version of sqlite3 this library was pinned to.

It's actually good software practice to decouple these kinds of dependencies as much as possible because it allows for such interchangeability.

We actually have the definitions copied into this repo from sqlite3 because we'd have to include the sqlite3 package for the types, which would break the idea above.

If the definitions have changed, you can always open a PR to update.

https://github.com/kriasoft/node-sqlite/blob/master/src/vendor-typings/sqlite3/index.d.ts

[ajanian]

I see. The copying of the types is what threw me off. I guess I don't understand why you would have a "half-dependency" (I'll call it that) on sqlite3. I totally understand the benefit of not depending on sqlite3. OTOH that isn't totally true, right? You still depend on the types, no? I feel like copying types into your package is a code smell. TBH I don't understand enough about the innards of your package and how it works so please feel free to disregard.

[theogravity]

This is no different than if I wrote my own typescript definitions by hand for sqlite3. It'd still be done without the original package being included, but why try to re-create something that already exists by hand?

The package is extremely simple if you look at the source code.

I hope with more practice in your software development, you'll eventually understand why we've decoupled it.

[ajanian]

I think the only reason would be to avoid the naming conflict.  When someone sees sqlite3.OPEN_READONLY available as a type they usually expect it to be available as an implementation.  In this case it wasn't because I didn't install sqlite3.  I think if you were to change the name of the copied types it would be a bit clearer. As I said, I do understand why it is decoupled

…

On Fri, Jan 29, 2021 at 1:21 PM, Theo Gravity < ***@***.*** > wrote: This is no different than if I wrote my own typescript definitions by hand for sqlite3. It'd still be done without the original package being included, but why try to re-create something that already exists by hand? The package is extremely simple if you look at the source code. I hope with more practice you'll eventually understand why we've decoupled it in the future. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub ( #138 (comment) ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAAYLBCPRJF47VY55PZ5EFTS4L4DLANCNFSM4WXINMZA ).

[theogravity]

That or you can read the readme:

https://github.com/kriasoft/node-sqlite#install-sqlite3