Dexie v4.0.1-beta.9
Pre-release
Pre-release
·
67 commits
to master
since this release
This is the last planned release in the series of small releases on the 4.0-track. The goal is to get a stable 4.0 release as soon as possible, but I'll wait to see some reports from usage before moving on.
Isolate readwrite transactions from live queries (#1881)
- Don't let dexie4's new cache get optimistic updates from explicit 'rw' transactions since it breaks isolation. Still, let "transaction-less" operations (no explicit transactions from user code) shine immediately through to liveQueries if cache isn't disabled in the constructor options.
- This makes dexie 4 behave exactly like dexie 3 when transactions are used, but may still optimize common liveQueries using the cache.
- Still, if there are 10 identical liveQuery subscriptions on a page, only one of them will need to requery IndexedDB after a write transaction and the other 9 will get their values from the cache. This is also the case after an explicit 'rw' transaction has committed.
Improved debugging experience (#1879)
- We're using Chrome's Async Task Tagging API to track failing operations down to the app code that initiated the operation. As long as Dexie.debug = true, we will print out call stacks in the console for any failed operation where the application code that initiated the operation is visible in the stack trace, no matter if the operation had to go through a bunch of async jobs before failing, such as implicitely opening the db in the backround, run some upgraders etc, while the only thing the user code did was a simple operation such as db.friends.get(1), but since it triggered a db open in the backround led to all these background work being performed. Before these situations were hard or almost impossible to track down to the application code.
- Fail fast on table.get(undefined) (To avoid unreadable call stacks like this: #1806 (comment))
- Remove old proprietary "long stacks" support that was tailored for older browsers and have no gain anymore.
Optimizations
- #1821 liveQueries of the form
db.someTable.orderBy('id').primaryKeys()won't be affected by a property change on an object of one of the observed keys, since the keys don't change. Only object adds and deletions will trigger the query to update.
Typings
- Use TInsertType in Table.update and Collection.modify (#1764)