Database

NOTE: This document is no longer maintained because the Web Applications Working Group was closed in October 2015 and its deliverables transferred to the Web Platform Working Group.

The purpose of this document is to provide a short summary regarding the relationships between WebApps' database-related specifications. By relationships in this context, we mean for example, are some specifications complimentary, are some specifications competing, do any of the specs specify overlapping functionality, etc. The summaries are high-level yet they do articulate the key relationships between these specs.

Status of this Document: this document is a Work In Progress and the contents do NOT necessarily reflect the consensus of the WebApps Working Group.

The WebApps WG has STOPPED all specification work on 1) Web SQL Database and 2) Programmable HTTP Caching and Serving (both of these document were published as Working Group Notes).

WebApps' Database-related Specifications

WebApps is working on the following database-related specifications. See PubStatus for the latest information about the publication status of these specs:

• Indexed Database API;
• Web Storage

The following documents are no longer active and have been published as Working Group Notes:

• Programmable HTTP Caching and Serving (aka DataCache API)
• Web SQL Database

Web Storage and Indexed Database API

Both APIs are based on a key-value record model and both use HTML5's structured cloning algorithm for storing and retrieving object values.

Web Storage and HTML5 Offline Application Cache

The Web Storage specification specifies two related mechanisms, similar to HTTP session cookies, for storing data (key/value pairs) on the client side:

1. The first storage mechanism is the sessionStorage attribute and it is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.

2. The second storage mechanism is the localStorage attribute and it is designed for storage that spans multiple windows, and lasts beyond the current session. Web applications may wish to store megabytes of user data, such as entire user-authored documents or a user's mailbox, on the client side for performance reasons.

HTML5's Offline Application Cache mechanism (aka AppCache) defines a mechanism - a manifest file - that a Web application can use to enumerate files that are needed for the application to work offline and which causes the user's browser to keep a copy of the files for use offline.

AppCache does not define any storage interfaces and as such defines orthogonal and complementary functionality to Web Storage.

Comparisons With Non-Active Specifications

NOTE: the comparisons in the following subsections include some specifications that are NO longer active!

DataCache API and HTML5's Application Cache

For some background information regarding WebApps' DataCache API spec and HTML5's Application Cache, see Caching In Off-line Web Applications by Oracle's Nikunj Mehta and Nikunj's email regarding a DataCache API and HTML5's Application Cache.

The Application Cache specified in HTML5 consists of a manifest listing URLs for a browser to precache so that a Web application can be accessed offline.

An application cache can hold static representations of a set of pre-defined resources that can be served locally.

The DataCache API Introduction says the following:

The standard HTTP caches built in to existing user agents are under no obligation to locally store a cacheable resource and do not provide any guarantees about off-line serving of HTTP resources. An application cache [HTML5] can hold static representations of a set of pre-defined resources that can be served locally. However, applications cannot alter this set of resources programmatically. Moreover, an application cache cannot satisfy requests other than GET and HEAD.

To address this limitation, this specification introduces data caches. Instead of a static manifest resource listing the resources to be cached, a data cache can be modified programmatically. Web applications can add or remove resources in a data cache which can then be statically served by the user agent when that resource is requested. This specification also provides embedded local servers to dynamically serve off-line representations of resources such as in response to unsafe HTTP methods, e.g., POST.

Private resources

Resources stored in an ApplicationCache are delivered independently of authorization headers and cookies. A DataCache only serves private resources if the ambient authorization satisfies the authorization condition on the DataCache. (according to its DataCaches model):

A secure data cache group controls access to private resources using an authorization cookie.

A secure data cache group is available to a cache host if its authorization cookie will be sent to an origin server for fetching that cache host [RFC2965].

Web SQL Database and Indexed Database API

The Web SQL Database and Indexed Database API specifications define overlapping functionality thus they are competing specifications.

The Web SQL Database specification (according to its Introduction):

Introduces a set of APIs to manipulate client-side databases using SQL. The API is asynchronous, so authors are likely to find anonymous functions (lambdas) very useful in using this API. According to the spec User agents must implement the SQL dialect supported by Sqlite 3.6.19.

The Indexed Database API specification (according to its Introduction):

Provides a concrete API to perform advanced key-value data management that is at the heart of most sophisticated query processors. It does so by using transactional databases to store keys and their corresponding values (one or more per key), and providing a means of traversing keys in a deterministic order. This is often implemented through the use of persistent B-tree data structures that are considered efficient for insertion and deletion as well as in-order traversal of very large numbers of data items.

Logical model

The two specifications differ in terms of the model used for storing data.

The Web SQL Database specification requires a relational model for data in the form of schemas described using DDL. The schema describes the columns that every row in a table is required to have, even if null values may be allowed for some of the columns. Web SQL Database API is used to store data in the form of rows and columns. A single row is retrieved from the database as a native ordered dictionary data type, which in ECMAScript terms is an Object by writing SQL that describes the criteria for locating the required data. The data for a row is stored in the database by either producing a SQL statement that contains all the values for the row or by binding an array of values to a SQL statement with placeholders. An index may be created on any table based on one or more of its columns. This index is maintained by the user agent. When processing SQL statements, these indices may be used for efficient retrieval.

The Indexed Database API specification requires a key-value record model for data, where the value is an object with properties. Every object holds at least one primitive key property. An object store is created through an API call using simple parameter values that are themselves not based on a sophisticated grammar, e.g., names or numbers. A single key-value record is retrieved from the database as a native ordered dictionary data type, which in ECMAScript terms is an Object. The data for a key-value record is stored in the database by making an API call and passing it the value object that contains the required key. A key-value record is retrieved by making an API call that either iterates over a range of keys in the object store or by identifying the key corresponding to the required record. An index may be created on any object store based on one or more of the properties in its value objects. This index is maintained by the user agent. An application has to explicitly use this index to efficiently identify objects it wants to retrieve.

Locking and concurrency

The two specifications offer different levels of concurrency for accessing and modifying data. Both offer at least one mode of concurrency error-free operation, even though in that mode timeouts are possible while waiting to start the transaction.

The Web SQL Database specification requires shared read access and exclusive write access (according to its Processing Model).

If the mode is read/write, the transaction must have an exclusive write lock over the entire database. If the mode is read-only, the transaction must have a shared read lock over the entire database. The user agent should wait for an appropriate lock to be available.

Sharing granularity is at the level of the entire database. In other words, either the entire database can be accessed or nothing can be accessed in the database. Moreover, a transaction is identified in advance to be read-only and that mode is not changeable.

The Indexed Database API specification supports the concurrency model of Web SQL Database as the default. In other words, the least use of programming power will result in a shared read access and exclusive write access model at the granularity of the entire database. Concurrency error-free operation is also supported at the level of groups of object stores. Finally, the programmer can choose to use database objects without pre-acquiring locks. In this mode, applications may receive transaction commit errors because of optimistic concurrency failure arising from conflicting locks or a deadlock due to conflicting locks. An implementation of Indexed Database API can even perform row-level concurrency management in the case when locks are not pre-acquired.