Explore to change to a different storage service implementation

[bpasero]

With Electron 3.0.x, the old SQLite based localStorage implementation will no longer be supported. We should think about coming up with our own storage solution for state. Related issues:

• Features
  • Allow globalState to be synchronized across multiple windows Allow globalState to be synchronized across multiple windows #55834
  • Allow non-renderer processes to read/write state
  • Add events to react on changes to global state across processes/windows
• Bugs
  • macOS: updating to a newer version often means UI state is lost macOS: updating to a newer version often means UI state is lost #39125
  • localStorage access is slow localStorage access is slow #18439

[bpasero]

I am opening this issue for feedback from anyone interested in this matter (and ideally having experience with SQLite).

My current thinking is this:

• use SQLite as new backend for anything that we store in window.localStorage today via the https://github.com/mapbox/node-sqlite3 node module
• use 1 database for all global state (there can only be one, managed by the main process)
• use 1 databases per workspace state (there will be many, managed by the renderer process)
• have 1 table per database (CREATE TABLE ItemTable (key TEXT UNIQUE ON CONFLICT REPLACE, value BLOB)) - inspired by Chrome's own usage of SQLite for localStorage (before they moved to LevelDB)
• leave the defaults of SQLite (do NOT set any PRAGMA)
• never have more than 1 process connect to a database (at least not for writing, reading is fine)

Implementation (in storage.ts)

• getItems(): SELECT * FROM ItemTable iterating over each result row
• setItems(): INSERT INTO ItemTable VALUES (?,?) as a transaction to speed up bulk inserts
• deleteItems(): DELETE FROM ItemTable WHERE key=? as a transaction to speed up bulk inserts

There will be a migration from the old localStorage DB to the new solution before any window opens.

[Astrantia]

@bpasero I'm not exactly sure if this is how the global state is supposed to work. Open up 2 insider editors, click ctrl+shift+x (to open extensions panel), resize it. Tab to the other vscode and notice that it hasn't been resized. Should it have been resized or not?
Another question, will update extensions without a reload feature land in this month's insiders? Thanks for all the work

[bpasero]

@Astrantia we decided to not synchronise state such as the sidebar width across windows because it can well be that you are on a multi-monitor setup where you want to have individual sizes per window. It would be crazy if we would always put the same size on all windows, that would make multi-window work very hard imho.

will update extensions without a reload feature land in this month's insiders

No

[bpasero]

The first part is merged to master, all workspace storage will be served from our own SQLite DB. Existing data is migrated out of window.localStorage.

[bpasero]

Via #64719

[Astrantia]

@bpasero I'm very curious about Updating extensions without a reload. Is vscode anywhere close to achieving it yet with having global storage implemented?

[bpasero]

@Astrantia a bit closer but not there yet