Welcome to trilogy Discussions!

[haltcase]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction — where have you been using trilogy?

[ozyman42]

Trilogy seems nice. One use case I have has the following requirements:

• be free of node-gyp
• don't store entire DB in-memory.

Unfortunately it seems like sqlite3 supports req 2 but not req 1 whereas SQL.js supports req 1 but not req 2. Will trilogy ever be able to help with my situation so for example we could have a fully cross-platform SQLite with SQL.js that doesn't store the whole thing in-memory?

[haltcase]

That's the tradeoff right now between the two backends, it's an inherent limitation of sql.js that the DB must be entirely loaded into memory.

It's totally possible that there are improvements trilogy could make for handling the use of this memory though, even if it's just to give more control to the user about when the DB is loaded/dumped.

I don't see trilogy as the place to solve the root of the issue though, as SQLite is written in C for native platforms and we're in some ways already lucky to have a useable implementation in JS at all.

It would be neat if future WASM APIs would make it possible to work with disk files incrementally but don't know of anything specifically being worked on there.

[ozyman42]

Another question. Why have you chosen sqlite3 over better-sqlite3? I'm not recommending one over the other, I'm just curious what your thought process was on that decision.

[haltcase]

Synchronicity debate aside, knex and better-sqlite3 are incompatible, so it would require an entirely different approach.