Dexie v3.0.0-alpha.6

Maintainance Release

This new release contains the latest fixes in master branch. I consider this release rather stable, despite the "alpha" status, which is due to that the new DBCore layer's API is still emerging.

This particular release does not contain any changes in DBCore from last alpha version.

Dexie-export-import

Although not part of the main npm package, one of the biggest news in the repository since last alpha version, is the new addon dexie-export-import which is already released as its own package on npm. That package can be used with either [email protected] or [email protected] stable.

Fixes

• #771 Don't console.warn() unless Dexie.debug is truthy
• #768 Issues with Collection.raw and Table.mapToClass
• #612 Native async/await and upgrade handlers
• #770 Using a database in an upgrade handler prevents subsequent upgrade handlers from running
• Bugfix for extracting index spec for handling dynamically opened outbound primkeys (commit 9718d95d9b3a434749079a7217412b8c9917c0e6)

Dexie v3.0.0-alpha.5

Fixes

• Remove stray debugger statement
• Update build-deps for dexie-observable
• Resolved issue #706

Redesign

The big difference in this release from v3.0.0-alpha.3, is how we call IndexedDB. Instead of calling it directly, it will go through a middleware-enabled stack, DBCore.

NOTE: This is an internal redesign. The external API is still the same as in Dexie 2.0 so you won't have to adapt to the new possibilities that comes with this redesign, unless you want to use the new middleware api (Dexie.use()).

This rewrite is part of reaching the goals in vision for dexie, specifically it will enable asynchronic work to be done in a middleware, which is something covered in here.

To use it in this version, do:

import Dexie from 'dexie';

const db = new Dexie('dbname');

db.use({
  stack: "dbcore", // The only stack supported so far.
  name: "MyMiddleware", // Optional name of your middleware
  create (downlevelDatabase) {
    // Return your own implementation of DBCore:
    return {
      // Copy default implementation.
      ...downlevelDatabase, 
      // Override table method
      table (tableName) {
        // Call default table method
        const downlevelTable = downlevelDatabase.table(tableName);
        // Derive your own table from it:
        return {
          // Copy default table implementation:
          ...downlevelTable,
          // Override the mutate method:
          mutate: req => {
            // Copy the request object
            const myRequest = {...req};
            // Do things before mutate, then
            // call downlevel mutate:
            return downlevelTable.mutate(myRequest).then(res => {
              // Do things after mutate
              const myResponse = {...res};
              // Then return your response:
              return myResponse;
            });
          }
        }
      }
    };
  }
});

As the DBCore interface is still being figured out, it can change. And there is still no official documentation about it. In essence, all mutating operations are bulk-oriented. Theres only bulkPut(), bulkAdd(), bulkDelete() and deleteRange(). Currently all of these four are reached through a single method mutate(). (This might change in future).

Interface definitions for DBCore is found here

In this version, the CRUD hooks are called from a built-in middleware: hooksMiddleware: A middleware that makes sure to call CRUD hooks in a backward compatible manner.

Dexie v3.0.0-alpha.3

Overview of Changes

• Improved Database Upgrading (see "Details" below)
• Improved Node support (when used together with IndexedDBShim on node)
• Failing gracefully when cookies are disabled in Firefox (#619). This fix was also committed to master-2 and release in latest stable (v2.0.4).
• #696 Possible to query multiple multiEntry properties using db.table.where({tags: 'browser', categories: 'database'}).
• #692 Console warnings with indexing advices shall only happen in debug mode.
• Improved tests

Details

Improved Database Upgrading (PR #714)

It is now possible to read data from a table in upgrader and delete the same table in a later db-version. It is now also possible to change a primary key of a table (on all platforms except IE and Edge). You could also change the table's name, or use data from one table into other tables, and then delete the origin table.

• Here's an example code that changes the primary key
• Here's an example code that changes the table name

This has been an issue for years, mentioned in #88, #105, #287 and #713.

To take advantage of the new upgrade support, upgrade() functions can only access such tables through the transaction instance given to the upgrade function (single argument) and not through the Dexie instance. The specific scenario that is now possible in 3.0.0-alpha.3 and later, is the following:

const db = new Dexie('MyDatabase');
db.version(1).stores({
  friends: 'name, age'
});
db.version(2).stores({
  friends2: '++id, name, age'
}).upgrade (tx => tx.friends.toArray().then(friends => {
  // As a part of renaming the table,
  // copy it to the new table friends2:
  return tx.friends2.bulkAdd(friends);
}));
db.version(3).stores({
  friends: null // delete friends table
})

What Did Not Work Before

In all previous versions of Dexie, upgraders could never access a table that was being deleted, even if it was being deleted in a later version than what the upgrade() was attached to. The upgrade() callback would fail due to missing table, as the table was already non-existing from the API point-of-view. So the upgrader in the above sample would fail with "NotFoundError Table 'friends' is does not exist".

IMPORTANT NOTICE

In order to access "death-sentenced tables" from an upgrader, it MUST access it through given upgrade transaction, and not just the global Dexie instance db.friends. A good practice henceforth is to always use the upgrade transaction, generally from upgrade callbacks. This is also backward compatible (Upgraders has always had the upgrade transaction as an argument, but it was not required to use it). Documentation of how to write upgraders are updated so that every upgrade() sample in the docs now use the given transaction instance.

Improved Node support

A lot of effort has been made to fix issues in Dexie when running on node (using IndexedDBShim. We're still seeing issues along the unit tests when running on node. One pull-request for IndexedDBShim has also been made. We're still not experiencing full IndexedDB compatibility on node though due to some remaining test failure of the dexie test suite when it runs on node (#709).

Improved Tests

Updated supported browsers to later versions (d2c24f4)
This release was successfully tested on the following browsers:

• Firefox 47
• Firefox 59
• Edge 13
• Edge 17
• IE 11
• Chrome 49
• Chrome 66
• Safari 10.1

Why still in Alpha?

In Dexie 3.0.0-alpha.1, all code was migrated to Typescript + splitted into smaller modules. The feature set is still almost identical to the stable 2.x version and is tested as rigorously. However, as the changes made to the code base were so large, I thought is was safe to increase the major version. Also, the d.ts files are completely rewritten, which implies breaking changes for Typescript users.

Until issue #659 is solved in one or other way, we will still be in alpha. If you experience problems using the library from your typescript code, please comment on #659. If you have ideas on how to fix it, please PR!

---

David Fahlander

Dexie v2.0.4

This patch release includes a bugfix: If disabling cookies in Firefox, Dexie.js failed to load (see PR #619).

Note that 2.x releases are now maintainance releases only and is backed by branch "master-2". The master branch maps to [email protected].

To install this release

npm install dexie

To install the very latest version,

npm install dexie@next

Dexie v2.0.3

Maintainance release

This release fixes issue #617: SecurityError when storage is disabled (again)

Dexie v3.0.0-alpha.2

PR #670: updating hook's onsuccess will get the updated object as documented, instead of the primary key.

PR #672: fix for setByKeyPath when removing array items

Dexie v2.0.2

Fix: PR #670: updating hook's onsuccess will get the updated object as documented, instead of the primary key.

Dexie v3.0.0-alpha.1

This is the first release after refactored dexie to typescript (Announcement #622, PR #653).

In summary, everything should work the same as latest stable, version 2.0.1.

To install:

npm install dexie@next

Keeping it on new major due to the massive rewrite and possible backward incompatibilities in the typings file (should only concern typescript users though). The only 2 known incompatibilities are:

1. When using dexie-relationships from a typescript perspective. It may not be able to declare the typings of extended table and collection methods correctly.
2. Requires a newer Typescript version (2.6.1 tested) to understand the d.ts file.

Dexie v2.0.1

Angular / Zonejs issue

• "Maximum call stack exceeded" with Zonejs 0.8.18 #589

Performance issue

• Performance issue of toArray() not using optimized getAll() (#591)

Dexie v2.0.0

At last, we have version 2.0.0 out and it is way more tested, compliant and bug free than the old 1.x branch.

I would bore you if listing all details since the last stable release (version 1.5.1 in November 2016) so I'll try to summarize it with focus on the most interesting parts:

Support for native and transpiled async / await

• Use async functions within database transactions without loosing track of current ongoing transaction.
• Compatible with Typescript 2.x, 1.x and babel.
• Compatible with even native async / await across all browser inluding Safari, Chrome, Edge and Firefox*. Firefox still suffers from this issue which makes native await calls loose the transaction. This is something that only can be adressed by the Mozilla team. NOTE: You can still do async/await within transactions and target Firefox - just make sure to not use native async/await, but transpile it to ES5 or ES6 using a transpiler such as Babel or Typescript!

IndexedDB 2.0 support

Unit tests of Binary Keys (IndexedDB 2.0 feature) has been fixed along with some issues in Dexie related to binary key support. Binary Keys are a more optimal way of storing binary data in IndexedDB. IndexedDB 2.0 supports any typed array (such as Uint8Array, Float64Array, etc) as well as ArrayBuffer to be indexed or used as primary key. Browsers that support IndexedDB 2.0 are: Firefox(*), Chrome, Opera and Safari.

(*) Firefox < 57 have an issue with using binary keys as primary keys. This issue was fixed recently and will be solved in Firefox 57 (a future release).

Native Safari (including Iphone) Support

Safari 10.1 is now at last fully IndexedDB compliant and part of the CI tests of Dexie. We run the Safari tests on an IPhone 7 device at browserstack.com. IndexedDBShim is no more needed when targeting latest version of Safari (10.1).

Full test matrix is now:

Browser	Version	OS	Auto-tested for each PR	Tested on publish (publish.sh)
Firefox	47	Debian	✔
Internet Explorer	11	Windows 7	✔
Firefox	55	Windows	✔
Safari	10.1	iOS	✔
Firefox	47	OS X		✔
Microsoft Edge	15	Windows 10		✔
Chrome	49	OS X		✔
Chrome	60	Windows		✔

We use travis ci and browserstack for continous integration and automatic pre-relase tests. If you'd like to extend the test matrix, please file a PR where you add your desired browser to karma.browers.matrix.js. You must also define the browser in karma.browserstack.js. Submitting the PR will tell whether it would work or not (just add your new browser to the "ci" array of karma.browsers.matrix.js and define the same browser in karma.browserstack.js).

NOTE: Integration tests of dexie-observable, dexie-syncable and dexie-relationships are still not tested against the full matrix quite yet.

A pick of other news...

• Dexie.waitFor() makes it possible to call non-indexedDB API:s (promise-returning async API:s!) without loosing the transaction.

• Simpler queries like:

  await db.friends.where({
      name: "Bobby",
      age: 42
  }).toArray()

  will try using a compatible compound index [name+age] if present (and browser supports it), else just utilizing one of the indexes and JS-filter on the second criteriea.
  See Table.where()

• Simpler way of getting a single row by index instead of primary key:

  const foo = await db.friends.get({email: '[email protected]'})

  See Table.get()

• Improved typescript definitions in general

• Much work has been put on rewriting and fixing issues in dexie-syncable and dexie-observable. Thanks @nponiros !

Backward Compatibility

Keeping backward compatibility is a number one priority for Dexie.js, so there are not a lot of API changes. However, some things need to change some time and a few API methods that have been deprecated for a time have gone obsolete. The full list can be viewed here: http://dexie.org/docs/Deprecations