Creating sql.js object which is using SQLite wasm file.
Depends on D6992
Details
Details
- Reviewers
michal tomek - Commits
- rCOMM2b354c58f0f6: [web-db] initialize SQLite database
Run this code:
declare var sqljsFilename: string;
const rawWebDbWorker = new SharedWorker('/worker/database');
const webDBWorker = new WorkerConnectionProxy(
rawWebDbWorker.port,
error => {
console.error(error);
},
);
const origin = window.location.origin;
await webDBWorker.scheduleOnWorker({
type: workerRequestMessageTypes.INIT,
sqljsFilePath: `${origin}/compiled/webworkers`,
sqljsFilename,
});And check if db version was properly logged on web and desktop
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- db-on-web-2
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| web/database/worker/web-db-worker.js | ||
|---|---|---|
| 30 | in current state this is always empty - there is no persistence mechanism yet | |
| web/database/worker/web-db-worker.js | ||
|---|---|---|
| 32–34 | Wondering if we have to hardcode the urls here. It seems like this depends on the configuration from commapp_url so if someone decides to e.g. configure the server on different port, this code will break. Not sure what is the right solution, but we can try:
| |
| 47 | Shouldn't we validate the returned data, so that we're sure that these arrays are not empty? | |
| web/database/worker/web-db-worker.js | ||
|---|---|---|
| 32–34 | It's more complicated than simply using window/self, eg. in the worker context, I am able to check only for the host (localhost:3000), but the file is under the path http://localhost:3000/comm/ so it's still part that needs to be hardcoded and it's defined in config. Can I create a follow-up task for this and figure out the best solution also for other cases (I think it's common to hardcode URLs, eg. in service worker)? | |
| 47 | Still in development so I read the value only for showing that we can query something. In the very near future, I will need to add some kind of mapper that will modify results and make data more accessible, then I will be able to type result.user_verision because there is access to columns' result. But adding checks for now | |
| web/database/worker/web-db-worker.js | ||
|---|---|---|
| 32–34 | Ok, we can do that. But we should probably prioritize it before the migration to the db so that we don't break workflows of some devs (we can also check if there are devs who use different config). | |
Comment Actions
Do we know how this diff corresponds to https://linear.app/comm/issue/ENG-3322/fix-stale-cache-error-for-olmwasm#comment-d1aabe3d? Maybe this will somehow improve the experience about the path's configuration?
| web/database/worker/db-worker.js | ||
|---|---|---|
| 62–64 ↗ | (On Diff #23696) | Should we somehow confirm that the initialization was successful? Or maybe the fact that no exceptions were thrown is good enough? |
Comment Actions
Example usage is in the test plan, unfortunately, it can not be done as elegantly as in olm case - where both web and .wasm file is hosted from the same place.
The worker file is hosted via different endpoint so using a relative path is not possible.
Comment Actions
Addressed in D7092
| web/database/worker/db-worker.js | ||
|---|---|---|
| 62–64 ↗ | (On Diff #23696) | I would rely on exception/no exception facts only, to avoid additional data. I responded here with more context: https://phab.comm.dev/D6991?id=23509#inline-46461 |
| web/database/worker/web-db-worker.js | ||
| 32–34 | This thing is now fixed by the latest changes caused by changing the file name, should be okay when devs have different configs I think | |