missing docs: web worker

[skyqrose]

The README says

If you don't want to run CPU-intensive SQL queries in your main application thread, you can use the more limited WebWorker API.

It gives a couple examples and caveats, but I need a lot more information to use the feature. I need a list of messages I can pass, what the worker will pass back, and a description of what the limitations are. There's no page on the website or GitHub wiki about this.

Other issues:

• The docs say to get the file from the releases page, but I'd rather get them from node_modules/sql.js/dist so they get version updates. But someone in this issue said that won't work. This is something that should be covered in a full explanation of how to use web workers.
• @types/sql.js is missing types for the web worker API.
• Existing issue caused by these missing docs: Is it possible to use transaction with web worker? #490

Because of these missing docs, for my app I'm going to write my own custom web worker using the normal SQL.js API.

I'll also highlight the proposal to remove the whole web worker API, which would be a way to avoid this whole issue (though you'd still want the docs to have some hints about how/why to write a custom web worker): #377

[lovasoa]

Hi ! That would be very useful indeed ! Do you want to write this documentation ?

The underlying worker code is quite simple; it's here: https://github.com/sql-js/sql.js/blob/master/src/worker.js

[scola84]

Would it be possible to add getRowsModified to the worker?

[lovasoa]

Yes! The code is here: https://github.com/sql-js/sql.js/blob/master/src/worker.js you can open a pull request. Don't forget to add a test for it !

[scola84]

Alright, I'll look into it next week.

If you look at for example https://github.com/brianc/node-postgres/blob/master/packages/pg/lib/result.js#L13, you can see that the rowCount is part of every query result. That would mean I could also implement something like:

return postMessage({
  id: data["id"],
  results: db.exec(data["sql"], data["params"], config),
  rowsModified: db.getRowsModified()
});

Do you think that is a good idea? (Maybe rowsModified should be in results?)
Or would you prefer just a getRowsModified action?

[lovasoa]

I think a separate action, preventing an new wasm call after each request, is better.

Just out of curiosity, do you have very strict performance requirements, or something else that prevents you from just using SQLite's built-in changes sql function?

https://www.sqlite.org/lang_corefunc.html#changes

[scola84]

I've created a PR.

I was not aware of the changes function since I have only very little experience with SQLite. I like your Worker API and with the addition of the getRowsModified function I have everything I need.

By the way, I noticed that when I execute a query with an empty result set, no headers are returned. In libraries for other SQL dialects this usually is the case. Is it specific to SQLite or to your library that no headers are returned in the case of an empty result set?

[lovasoa]

You can use Statement.getColumnNames to read the column names. But it's not in the web worker api.

[scola84]

OK, thanks. Now I understand the remark "you can use the more limited WebWorker API" on the website. Maybe I'll switch to the initSqlJs approach later, for now the Worker will do.