Architecture Overview

From the start, lokijs has attempted to leverage familiarity with the mongo db api to create a fast, lightweight, in-memory database, with no library dependencies that can run and persist anywhere.

As Loki has evolved, it has kept and expanded on its core Mongo similarities while also augmenting that feature set with a versatile Fluent API interface for constructing queries, as well as a dynamic view interface for keeping live views of queries. Each of these interfaces work together to provide an interface which allows powerful and fast querying and transformation capabilities.

'Find' - Core Mongo capability

Lokijs currently implements following mongo functions with simplified options :

• find()
• findOne()
• ensureIndex()
• insert()
• update()
• delete()

Lokijs also currently implements the following find() operators :

• $eq. $ne
• $gt, $gte
• $lt, $lte
• $in
• $contains
• $regex
• $and
• $or

'Where' Filter functions

Lokijs also supports the use of javscript filter functions to allow the user the ability to cover complicated edge case queries which may not neatly fit into the mongo query structure. These 'where()' functions are not serialized along with the database so employing them requires the user to ensure to maintain and provide to lokijs to execute as needed. Any 'where' filter functions you utilize will also not be able to utilize any collection indexes.

Loki Class structure :

Event Emitter

This allows internal and external notification of internal events. As actions are performed with the loki database, these events allow the means to monitor, manage or extend functionality of these internal processes. Database, Collection, and DynamicView currently inherit and implement this Event Emitter functionality.

Database

The primary entry point for dealing with Lokijs, this class hosts all others and acts to create, manage, and serialize the database as a single entity.

###Collection This entity maintains all of its documents internally and provides 'core' api interface to those documents. Indexes are maintained, documents are added, updated and removed, meta is generated, objects cloned, changes are optionally tracked, and events established. Collections also provide the core document querying capabilities via find() and where().

###Resultset This entity primarily establishes a 'state' for queries. Internally, this state is represented as a filtered set of indices to documents of a specific collection. For multi-criteria or complex set query operations, the resultset can set up more complicated query pipelines and even makes those available to collection core api.

###DynamicView What the Resultset lacks is its dependence on static database state. Resultset is meant to perform instant action to obtain results or modify the database within the context of its current state. DynamicView attempts to allow the complex query pipelines (established via resultset), to remain valid thoughout the volatile life of database modifications.

###Persistence Adapters This adapter interface establishes a plug-in system for persisting the database to different storage mechanisms (such as indexedDB). Primarily intended for application to any variety of key/value data stores.

###Autosave Timer An option exists for you to pass into the loki constructor, to perform automatic, periodic database saves (provided changes are pending). This timer may evolve into a scheduler for other tasks in the future.