1.0 to 1.1 Upgrade Notes and Guide

Placeholder for more readable summary of what's new in 1.1, to be expanded upon later in appropriate detail :

Loki 1.0 -> 1.1 Upgrade Notes and Changelog

loki id property renamed to $loki

The autogenerated 'id' column on inserted loki objects has been renamed to '$loki'. This is probably the only breaking changed introduced, but in the future it will be less likely to conflict with objects that already have an 'id' column. If you have saved databases in 1.0 format loki should be able to load it and convert it to new id system. If your 1.0 database had user id renamed to originalId, loki should restore it with 'id' renamed to '$loki' and 'originalId' renamed back to 'id'. The next time the database is saved it will be in 1.1 format. Loki can't upgrade your code though, so if you have been explicity using the 'id' column, perhaps to simulate relations / foreign keys or for list/grid binding, you will need to update that to use $loki.

Collections constructor

Collections now take a name parameter and an options object. The possible parameters in the options are:

• indices: array of fields to be indexed
• transactional: is the collection transactional (a fallback mechanism in case things go wrong during operations)
• asyncListeners: event listeners can be made sync or async
• disableChangesApi: enable/disable the Changes API (see below)
• cloneObjects: you can force LokiJS to create clone copies of objects instead of using the original objects

Changes API

The Changes API enables the tracking the changes occurred in the collections since the beginning of the session, so it's possible to create a differential dataset for synchronization purposes (possibly to a remote db). See the wiki page for detailed usage.

Enhancements to loki persistence layer (autosave/autoload)

More versatile configuration of persistence method along with optional autosave and autoload capabilities. See LokiJS persistence and adapters wiki page for detailed description.

Added indexeddb adapter

See LokiJS persistence and adapters wiki page for detailed description.

Added clone object option to specify loki should clone inserted documents

By default, when you insert and object into a LokiJS database, it refers to your object reference rather than create its own copy. If you prefer LokiJS clone its own copies you can specify collection level clone option.

Compound sort for sorting on multiple columns

For chained multisort, some examples include :

rs.compoundsort(['age', 'name']); // to sort by age and then name (both ascending)
rs.compoundsort(['age', ['name', true]); // to sort by age (ascending) and then by name (descending)

For DynamicView view, some examples include :

dv.applySortCriteria(['age', 'name']); // to sort by age and then name (both ascending)
dv.applySortCriteria(['age', ['name', true]); // to sort by age (ascending) and then by name (descending)
dv.applySortCriteria(['age', true], ['name', true]); // to sort by age (descending) and then by name (descending)

Renamed ensureBinaryIndex() to ensureIndex()

If you apply your own indexes outside of the collection constructor options, you need to call :

ensureIndex(propertyName);

or

ensureIndex(propertyName, true);

to force index to be built immediately.

Added asyncListeners option (Events can be sync or async)

By default in LokiJS 1.0, listeners were triggered in an async fashion. This would grant a performance boost but it would also make it tricky to test. You can set whether events are going to be sync/async at collection level, by passing the option { asyncListeners: true|false }. This grants a more granular control and makes it easier to create tests.