IndexedDB is an exciting option for offline storage in the HTML5 sites and applications that you build. The API's not ready yet, but it's important to play now, and feed your experience into the ...
IndexedDB is an exciting option for offline storage in the HTML5 sites and applications that you build. The API's not ready yet, but it's important to play now, and feed your experience into the standards process.
Parashuram Narasimhan, Researcher You could also check out http://nparashuram.com/ttd/IndexedDB/index.html for IndexedDB examples2 years ago
Are you sure you want to
\n
This stuff is completely beta at the moment. It’s only implemented in Firefox 4 and Chrome dev channel, so it’s not anything that can be used for production projects in the near future. Microsoft and Opera are contributing to the spec, however, and Google is working on pushing the code upstream to Webkit itself, so this looks like something that will be more and more relevant going forward. \n\nSince the spec’s not finished, and everything’s in dev mode, this is a _great_ time to examine the API, and experiment. We need to play around with this code, and feed our experience back into the standards bodies and browser vendors: that’s the best way to ensure that things work the way we want them to when everything’s solidified.\n
One of the most exciting recent realizations in web development is that the offline bits of the HTML5 suite of specifications are _really ready_ for widespread use. It's possible to store arbitrary amounts of information on a user's computer without resorting to opaque hacks like Flash storage, while at the same time making that information available in useful ways to your program's code. This opens up a whole new world of sites and applications which we're only just beginning to appreciate. Offline's important, and not just because of the Web Store.\n\n
What I'd like to do here is take a very brief survey of the landscape for context, and then dive into one particular feature that I think will become important in the near future: IndexedDB.\n\n
These aren’t even offline, but let’s take a quick look at why they’re not enough. :)\n
\n
\n
This is probably the best way to start with offline storage, as the API’s trivial. You’ll have to build your own indexing solution, however, which might be a bit more work than you were looking for.\n
Yes, stacking many file cabinets on top of each other is a nice way to increase your storage, at the expense of complexity (you’ll need ladders), and danger (you might fall off). That’s pretty much how I feel about WebSQL.\n
\n
\n
I know nothing about the File API, but Seth’s going to tell us all about it shortly. I’ll be all ears. :)\n
• Simple, key/value pairs, Cookies “shared” between server and client.• Excellent for maintaining state, poor for anything else, as they are unstructured, and incur a significant overhead for each HTTP request.
Local Storage http://www.flickr.com/photos/photohome_uk/1494590209/
Local Storage • The simplicity of cookies, tuned for higher-capacity, client-side-only storage. • Dead simple API: localStorage.setItem( ‘key’, ‘value’ ); localStorage.getItem( ‘key’ ); // ‘value’ • Values are unstructured strings: • Filtering and search are O(n), unless you layer some indexing on top. • Structure requires JSON.stringify & JSON.parse
WebSQL• A real, relational database implementation on the client (SQLite)• Data can be highly structured, and JOIN enables quick, ad-hoc access• Big conceptual overhead (SQL), no finely grained locking• Not very JavaScripty, browser support is poor, and the spec has been more or less abandoned.
File API http://www.flickr.com/photos/daddo83/3406962115/
IndexedDB• Sits somewhere between full-on SQL and unstructured key-value pairs in localStorage.• Values are stored as structured JavaScript objects, and an indexing system facilitates filtering and lookup.• Asynchronous, with moderately granular locking• Joining normalized data is a completely manual process.
IndexedDB Concepts
Practically everything isasynchronous. Callbacks are your friends.
Databases are named, andcontain one or more named Object Stores
contacts
Object Stores define a propertywhich every stored object mustcontain, explicitly or implicitly.
contacts 1 2 3 4 5 6 7 8 9
Values in an Object Store are structured, but don’t have a rigidly defined schema.
contacts 1 2 3 4 5 6 7 8 9
Object Stores can contain oneor more Indexes that make filtering and lookup possible via arbitrary properties.
contacts 1 2 3 4 5 6 7 8 9
IndexedDB API
T A ] [ B EIndexedDB API
Vendor prefixes:webkitIndexedDB & moz_indexedDB
// Deal with vendor prefixesif ( "webkitIndexedDB" in window ) { window.indexedDB = window.webkitIndexedDB; window.IDBTransaction = window.webkitIDBTransaction; window.IDBKeyRange = window.webkitIDBKeyRange; // ...} else if ( "moz_indexedDB" in window ) { window.indexedDB = window.moz_indexedDB;}if ( !window.indexedDB ) { // Browser doesn’t support indexedDB, do something // clever, and then exit early.}
Database creation is asynchronous
var dbRequest = window.indexedDB.open( “AddressBook”, // Database ID “All my friends ever” // Database Description);// The result of `open` is _not_ the database.// It’s a reference to the request to open// the database. Listen for its `success` and// `error` events, and respond appropriately.dbRequest.onsuccess = function ( e ) { ... };dbRequest.onerror = function ( e ) { ... };
Databases are versioned...
// The `result` attribute of the `success` event// holds the communication channel to the databasedbRequest.onsuccess = function ( e ) { var db = e.result; // Bootstrapping: if the user is hitting the page // for the first time, she won’t have a database. // We can detect this by inspecting the database’s // `version` attribute: if ( db.version === “” ) { // Empty string means the database hasn’t been versioned. // Set up the database by creating any necessary // Object Stores, and populating them with data // for the first run experience. } else if ( db.version === “1.0” ) { // 1.0 is old! Let’s make changes! } else if ( db.version === “1.1” ) { // We’re good to go! } // ...};
... and versioning is asynchronous.
dbRequest.onsuccess = function ( e ) { var db = e.result; if ( db.version === “” ) { // We’re dealing with an unversioned DB. Versioning is, of // course, asynchronous: var versionRequest = db.setVersion( “1.0” ); versionRequest.onsuccess = function ( e ) { // Here’s where we’ll set up the Object Stores // and Indexes. }; } // ...};
Creating Object Stores and Indexes
dbRequest.onsuccess = function ( e ) { var db = e.result; if ( db.version === “” ) { var versionRequest = db.setVersion( “1.0” ); // Setting a version creates an implicit Transaction, meaning // that either _everything_ in the callback succeeds, or // _everything_ in the callback fails. versionRequest.onsuccess = function ( e ) { // Object Store creation is atomic, but can only take // place inside version-changing transaction. var store = db.createObjectStore( "contacts", // The Object Store’s name "id", // The name of the property to use as a key true // Is the key auto-incrementing? ); // ... }; } // ...};
dbRequest.onsuccess = function ( e ) { var db = e.result; if ( db.version === “” ) { var versionRequest = db.setVersion( “1.0” ); versionRequest.onsuccess = function ( e ) { var store = db.createObjectStore( "contacts", "id", true ); store.createIndex( “CellPhone”, // The index’s name “cell”, // The property to be indexed false // Is this index a unique constraint? ); }; } // ...};
Writing Data (is asynchronous)
// Assuming that `db` has been set somewhere in the current// scope, we use it to create a transaction:var writeTransaction = db.transaction( [ “contacts” ], // The Object Stores to lock IDBTransation.READ_WRITE // Lock type (READ_ONLY, READ_WRITE));// Open a contact store...var store = writeTransaction.objectStore( “contacts” );// ... and generate a write request:var writeRequest = store.add( { “name”: “Mike West”, “email”: “mkwst@google.com”} );writeRequest.onerror = function ( e ) { writeTransaction.abort();};// Transactions are “complete” (not “committed”?) either when// they fall out of scope, or when all activities in the// transaction have finished (whichever happens last)writeTransaction.oncomplete = function ( e ) { ... };
Reading Data (is asynchronous)
// Assuming that `db` has been set somewhere in the current// scope, we use it to create a transaction:var readTransaction = db.transaction( [ “contacts” ], // The Object Stores to lock IDBTransation.READ_ONLY // Lock type (READ_ONLY, READ_WRITE));// Open the `contact` store...var store = readTransaction.objectStore( “contacts” );// ... and generate a cursor to walk the complete list:var readCursor = store.openCursor();// Setup a handler for the cursor’s `success` event:readCursor.onsuccess = function ( e ) { if ( e.result ) { // You now have access to the key via `e.result.key`, and // the stored object via `e.result.value`. For example: console.log( e.result.value.email ); // mkwst@google.com } else { // If the `success` event’s `result` is null, you’ve reached // the end of the cursor’s list. }};
Querying (is asynchronous)
var t = db.transaction( [ “contacts” ], IDBTransation.READ_ONLY );var s = t.objectStore( “contacts” );// ... and generate a cursor to walk a bounded list, for example// only those names between M and P (inclusive)var bounds = new IDBKeyRange.bound( “M”, // Lower bound “Q”, // Upper bound true, // Include lower bound? false // Include upper bound?);var readCursor = store.openCursor( bounds );// Setup a handler for the cursor’s `success` event:readCursor.onsuccess = function ( e ) { // process `e.result`};
Further ReadingThe IndexedDB Spec:http://www.w3.org/TR/IndexedDB/“Firefox 4: An Early Walkthrough of IndexedDB”:http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/Mozilla Developer Docs:https://developer.mozilla.org/en/IndexedDB
Questions? Mike West @mikewest mkwst@google.com http://mikewest.org/
1–1 of 1 previous next