Jsormdb architecture

From Jsorm

Jump to: navigation, search

Contents

Overview

jsormdb is architected as a series of JavaScript object components that interlink. The design is intended to be as modular as possible, allowing for easy replacement of parts or development and installation of plugins by any developer.

Programming Style

The programming style of jsormdb follows Douglas Crockford's rules of style as much as possible. Anyone developing in JavaScript should read as much as possible from his site, and pick up a copy of his excellent book

  • All objects are direct functions, rather than constructor-based objects. The keyword "new" is never used. To create a new database object, one uses
var db = JSORM.db.db(config);

instead of

var db = new JSORM.db.Db(config);
  • Objects creators are always lower-case, since they are not intended to be used with the "new" keyword.
  • Objects that extend other objects are done via a specialized extend function, JSORM.extend(). At core, this extend() function uses Crockford's power constructor.
  • Objects that require event management, like the database JSORM.db.db, use JSORM.eventualize(), which adds event handling. JSORM.eventualize() is inspired by and grows from Crockford's event handling recommended in his book.
  • Where possible, privileged functions are used rather than making everything, including private methods, members of the object itself.

Utility Extensions

Several utility functions have either been created on the JSORM object or extend existing classes. These are listed in JSORM_Utility.

Architectural Design

Classes

  • JSORM: A general container for all JSORM related features. There are a number of basic extensions to JavaScript here, some developed independently by the jsorm project, some inspired by Douglas Crockford. For the details, see the [jsorm] entry.
  • JSORM.db: A parent container for all of the jsormdb-related components.
  • JSORM.db.db: The actual db element. Instantiated as db = JSORM.db.db(config). See below for more detailed usage.
  • JSORM.db.parser: A parent container for all of the parsers. Parsers convert between input items and JavaScript objects, including metadata. Parsers are not strictly required for using jsormdb. The data can be entered directly into the database using classical inserts, and extracted using get. Parsers are only required for transmitting data to/from a remote data source, i.e. when marshalling/unmarshalling is required. Currently, only the json parser is available.
  • JSORM.db.parser.json: Parser to convert between JSON data as a string and JavaScript objects, including metadata required to load into jsormdb.
  • JSORM.db.channel: A parent container for all of the channels. Channels are used to communicate between the local jsormdb and a remote data source. Thus, parsers convert the data between the remote data source's "language" and JavaScript objects properly suited for jsormdb, while channels handle communication.
  • JSORM.db.channel.http: A channel to communicate via Ajax with the Web server over http.
  • JSORM.db.engine: A parent container for all local storage engines. Storage engines are responsible for maintaining tables. Currently, only the hash engine is included.
  • JSORM.db.engine.hash: An implementation of a table as an in-memory hash.
  • JSORM.db.index: A parent container for all local indexes. Currently, only a hash index is included. A B-tree index is under development.
  • JSORM.db.index.hash: An implementation of an index as a hash.

Heart

At the heart of the jsormdb is the class JSORM.db.db. This class is the core database, and is responsible for intermediating between the user on the one hand, and the data store(s) on the other. The db is responsible for:

  • Creating data tables
  • Loading data
  • Translating queries into functions that can find results
  • Journalling transactions
  • Handling reject or commit of transactions

The underlying mechanisms for many of these is delegated to other classes.

Storage

The db itself does not handle storage. Rather, it delegates storage to a storage engine, normally within the class JSORM.db.engine. For example, the hash engine is in JSORM.db.engine.hash. The db is engine-agnostic; as long as the engine follows the interface contract, the database will work with it. A user creating a database can request a particular engine, or simply use the default. The default is JSORM.db.engine.hash.

MORE TO COME...

Personal tools