Closed dusty-phillips closed 3 years ago
Ok, thanks!
This is because RangeSet class depends on indexedDB.cmp(). Could put the RangeSet constructor on the db instance and generate one per db instance (as doing with Transaction, Table, Collection etc). I am though very tempted to do a breaking change here and stop accepting the {indexedDB, IDBKeyRange} as options because static methods like Dexie.delete() would anyway need to be configured by setting the static deps in Dexie.dependencies globally.
import indexedDB from "fake-indexeddb"; // 3.1.3
import IDBKeyRange from "fake-indexeddb/lib/FDBKeyRange.js";
// Configure DOM dependencies on static prop
Dexie.dependencies.indexedDB = indexedDB;
Dexie.dependencies.IDBKeyRange = IDBKeyRange;
// ...is needed before calling static method Dexie.delete():
await Dexie.delete("MyDatabase");
Might need to bump version to 4.0 if so. The thing is - is it worth it having a lot of plumping code just to support per-instance IDBFactory? Maybe it is? Thoughts?
I can only think of one use case for per-instance configuration: parallel unit tests. But I think that can be approximated by having the one global dependency and using different database names for each dexie instance. I’ll try it and get back to you.
From a marketing/social perspective, having an excuse to launch Dexie 4.0 with dexie-cloud 1.0 might help garner some attention. 😉
Confirmed: copy-pasting your dependency setup code and appending a Math.random
to the name solves the parallel test case.
Thanks for your thoughts! I'll keep this issue open for some days before taking a final decision. Anyone feel free to weigh in. To sum up:
Dexie has since one of its earliest versions, had the option to replace the DOM dependency of indexedDB with another providers (such as indexedDbShim or fakeIndexedDB) - this way it can run in node (for example in unit tests).
There have been two ways of configuring the DOM dependencies:
Dexie.dependencies.indexedDB
and Dexie.dependencies.IDBKeyRange
to the alternate implementationsThe latter one is a bit more elegant but does not solve how to replace indexedDB in static methods like Dexie.delete()
, Dexie.exists()
and Dexie.getDatabaseNames()
.
This issue has been a bug since dexie@3.1.0-alpha.1 (the one with liveQuery()) that has a new dependency to indexedDB.cmp() that needs to be accessed in situations when we do not have a db instance - so we don't know which implementation of indexedDB.cmp() to use.
We could replace the dependency to indexedDB.cmp() by using a JS implemention of the same. But that would increase the code size and could potentially introduce bugs in case the JS implementation would differ from the native in some way - so we would need to have it yet another time in beta or rc before releasing it stable.
Just discovered something is still odd with fake-indexeddb and the latest Dexie release candidate.
It seems to be able to add data to the database and retrieve it just fine, but actually there is an error on
put
andadd
calls.Best described with a repro:
I'm guessing that Dexie is trying to access the global indexedDB at some point, rather than the one passed into the options on the constructor. Here's the trace: