Releases: dexie/Dexie.js
Dexie v4.0.1-beta.14
Support for sync-consistently moving tree structures (via PR #1910)
- New version of dexie-cloud-addon: 4.0.1-beta.58
- New version of dexie: 4.0.1-beta.14
- New export in 'dexie': replacePrefix
- New support for replacePrefix in Dexie Cloud
Background: The parentPath pattern:
One pattern for managing tree structures in a database is to have an indexed property representing the path to the parent node, such as parentPath. This makes it efficient to delete or list all descendants in one query without any need of recursion:
// Add new node
function addNode(childProps, parentId = null) {
return db.transaction('rw', db.treeNodes, async ()=> {
const parent = parentId && await db.treeNodes.get(parentId);
await db.treeNodes.add({
...childProps,
parentPath: parent
? `${parent.parentPath}${parent.id}/`
: '' // If no parent, parentPath will be empty string (added at the root)
});
}
}
// List direct children
function listChildren(node) {
return db.treeNodes.where({parentPath: `${node.parentPath}${node.id}/`}).toArray();
}
// List all descendants without recursion:
function listAllDescendants(node) {
return db.treeNodes.where('parentPath').startsWith(`${node.parentPath}${node.id}/`).toArray();
}
// Load parent
function loadParent(node) {
return db.treeNodes.get(node.parentPath.split('/').at(-2));
}
// Load all ancestors
function async loadAllAncestors(node) {
return (node.parentPath
? await db.treeNodes.bulkGet(node.parentPath.substring(0, node.parentPath.length - 1).split('/'))
: []
);
}
// Delete the node and all its descendants:
function deleteNode(node) {
return db.transaction('rw', db.treeNodes, () => {
db.treeNodes.where('parentPath')
.startsWith(`${node.parentPath}${node.id}/`)
.delete();
db.treeNodes.where({
parentPath: node.parentPath, // for consistence
id: node.id
}).delete();
});
}
// NOTE:
// Where schema is defined, use a compound index on '[parentPath+id]':
// db.version(x).stores({
// treeNodes: 'id, [parentPath+id]' // enables where({parentPath: X, id: Y})
// });All the mutating operations above are also sync consistent: If one offline client adds a child under "/a/b/c" and another offline client modifies all descendants under "/a/b/c" to have a new property {color: "blue"}, the merge of these operation will set {color: "blue"} on the added child also no matter in which order the clients became online. This works due to Dexie Cloud's built-in CRDT capabilities without the user having to use certain types in the objects they are storing.
The new support for moving trees
But modify-operations that use a JS callback does not benefit from sync consistency, only local consistency. Moving an entire tree from one node to another has been one of those operation that need a JS function because the new parentPath's value depends on its existing value. So a tree move has only been possible with local consistency but not sync consistency before:
function moveNode(node, newParentPath) {
return db.transaction('rw', db.treeNodes, () => {
// Move node. Having the parentPath criteria here is for consistency:
// Only perform the 2 moves if parentPath is still the same.
db.treeNodes.where({
parentPath: node.parentPath,
id: node.id
}).modify({
parentPath: newParentPath
});
// Move all its descendants in relation to their sub path:
db.treeNodes.where('parentPath').startsWith(`${node.parentPath}${node.id}/`).modify(node => {
// This is a JS callback that cannot be expressed to the server
node.parentPath = newParentPath + node.parentPath.substring(node.parentPath.length);
});
});
}JS code cannot securely be sent to the server due to several reasons: closures information missing + the risk of sending code that injects arbitrary code on the server. The operation above won't be sync consistent. If an offline client did add a new node under /a/b/c and that node is moved to /x/y/z, the merging of these operations would not be consistent - a node would still be placed under /a/b/c even though the c node has moved and doesn't exist anymore. So there is a need for declarative ways of doing certain operations, and moving trees is one of them.
A new export replacePrefix now available for this purpose. We will add more of these in coming versions (such as increment, push, deleteArrayItem, etc). replacePrefix is the first "complex" operation that already has support in Dexie Cloud (if upgrading dexie-cloud-addon to 4.0.1-beta.58) and can be executed to perform sync consistent tree moves:
import { replacePrefix } from 'dexie';
// Move subtree with sync consistency:
function moveNode(node, newParentPath) {
return db.transaction('rw', db.treeNodes, () => {
// Move node
db.treeNodes.where({
parentPath: node.parentPath, // consistency-check
id: node.id
}).modify({
parentPath: newParentPath
});
// Move all its descendants in relation to their sub path:
db.treeNodes
.where('parentPath')
.startsWith(`${node.parentPath}${node.id}/`)
.modify({
// Here we're in a declarative object - not a JS callback - ==> Consistent operation.
parentPath: replacePrefix(node.parentPath, newParentPath);
});
});
}This transaction does it all - it moves the node and all its descendants consistently in one atomic all-or-nothing transaction but also preserves the where-condition and the replacePrefix operation in the information to the server so that if an offline client added a node under /a/b/c, and then this operation happened, moving all descendants to the new location, and then the offline client comes online again and syncs, the new node would be placed on the correct new location and be hanging below a non-existing /a/b/c.
Consistency in conflicting move operations
If two operations competes in a move operation involving the same nodes, consistency is maintained by the extra criteria on parentPath in both the move of the parent node and the operation to move its descendants. A move operation will not be performed if another move operation came first. The end result will always be a consistent tree. The last syncer might then experience that the move operation they made got rolled back after a sync and they would instead see the peer's hierarchy.
Dexie v4.0.1-beta.11
Minor fix: Since 4.0.1-beta.10, we're allowing argument { disableAutoOpen: false} to db.delete() (not yet in docs), but it still failed if doing it.
Dexie v3.2.6
Bugfix
- Resolve #1883: Exception when having nested index and inserting null value of nested parent (cherry-picked from 4.0.1-beta.10)
Dexie v4.0.1-beta.10
Fixed bug introduced the recent release dexie@4.0.1-beta.7
- Support for bfcache (to resolve #1776) had an issue that pagehide event resulted in closing down Dexie instances to a state where they did not auto-open again on pageshow.
- The closing of connections happened no matter if event was a true bfcache event or not (didn't check the persisted property correctly)
Other
- Fixed #1883 Exception when having nested index and inserting null value of nested parent.
- Removed workarounds for IE11 as we are not supporting IE11 anymore
Dexie v4.0.1-beta.9
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)
dexie-export-import@4.1.1
Dexie v3.2.5
Bugfixes
- Fix issue with BigInt64Array (#1890) (and BigUint64Array) - cherry picked from 4.0.1-beta.8
- Workaround for UnknownError in. Chrome
v4.0.1-beta.8
NOTE: We're aiming for a stable 4.0 to be released as soon as possible. To get there, we're releasing new versions quite frequently now. Reason: splitting up major changes into smaller releases allows users to revert versions in steps rather than the whole version.
Changed Version Handling (See PR #1880)
- Dexie will now accept upgrading schema WITHOUT incrementing the version number
- Dexie will now be able to open a previous version of the database without complaining
Version numbering is now only useful when you need to:
- ...migrate the data (attaching an
.upgrade()onto a version. - ...delete tables
Other issues:
- Fix issue with BigInt64Array (#1890)
Dexie v4.0.1-beta.7
This is the first release in a series of small releases on the 4.0-track before it goes release candidate. Expect a few additional beta versions coming out soon. The goal is to get a stable 4.0 release as soon as possible.
Dexie Cloud
- Dexie Cloud Manager where you can purchase a production subscription, manage database login policy, describe your databases and view and upgrade individual users. Also possible to specify a custom SMTP settings to relay all OTP and invite emails.
- Latest version of dexie-cloud-addon is 4.0.1-beta.56.
- Allow database owners to troubeshoot issues that their users are facing. A database owner with full access to the all database content through the API or through
npx dexie-cloud exportcan now also login to their app with " as " in the email field and get the OTP sent to their own email but be authenticated as the other user. - Support {otp, otpId} as arguments to db.cloud.login(). The parameters must come from an OTP challenge. This will bypass the login dialog and directly authenticate the user. Usefule when customizing email templates to generate magic links with the otp and otpId as part of the query to the app.
Bugfixes
dexie-export-import
Other
- Expose the optional TInsertType of Dexie.Table generic: c94e9e8
Dexie v4.0.1-beta.6
dexie@4.0.1-beta.6
- Don't patch Promise.prototype.then (#1293)
- Resolved #1858 'Entity' is not exported from 'dexie' (imported as 'Entity')
- Fixes to run on LambdaTest (#1752). The migration from Browserstack to Lambdatest is now complete.
dexie-cloud-addon@4.0.1-beta.54
- Resolved #1724: Allows plus signs in email address (in order to use a single email address act as multiple users for testing)
- Resolved dexie/dexie-cloud#4 - Automatically make "email" property of "members" lowercase and trimmed (avoid inviting members with different casing in email address)