IndexedDBViewer: Take a look inside your indexedDB

Some days ago I released a new version of the IndexedDBViewer 1.1.0. The IndexedDBViewer is intended for web developers who want to sneak into their indexedDB database. It allows you to inspect the structure of your database as well as the data stored inside this structure. The difference with the previous version is that it no longer needs the jQueryUI library. This way I eliminated at least one reference. The following references are still necessary:

• jQuery (version 1.8.2 or higher)
• linq2indexedDB (version 1.0.19 or higher)
• indexedDBViewer (1.1.0 – JavaScript + css file)

If you are using nuget, you can get all the resource by searching for the indexedDBViewer.

The second major change is that the viewer can easily be added to an existing page. The only thing you need to do is add a div with “indexedDBViewer” as id and data-dbName attribute to pass the database you want to inspect. The rest will be handled by the script in the viewer

   1: <div id="indexedDBViewer" data-dbName="database name"></div>

Once this is done and you navigate to the page with the viewer, you will get the following result

In the bottom you will see the view appear. On the left pane you get an overview of the database structure. This a list with on top the name of the database. Under that you will find child nodes that represent the object stores present in the database. If we descend an other level we can see the indexes present on the object store. If you click on the “+” or “-“ next to the names, you can expand or hide the structure beneath.

If you click on the database name in the navigation pane, you will get information about the database and it’s structure.

• In the general block you will see the name of the database and the version it is currently in
  
• The object stores block gives you an overview of all the object stores present and how they are configured.
  
• The indexes block shows all the present indexes and how they are configured.

When you click on one of the object store names in the navigation pane, you will get all the data present in the object store. Because the data is saved as a key/value pair, you will see the key with his corresponding value. If the value is an object or contains objects, then you can inspect them by clicking on the “+” to expand and “-” to hide the details.

If you click on one of the index names in the navigation pane, you will get – similar as for object stores – all the data present in the object store. But in this case you will see a little more. Besides the key of the index and the value you will see the key the value has in the object store. This can be found under the “primary” key column.

As last there are some little extra features:

• If you click on the top border of the viewer and drag it up or down, then you can change the height of the viewer.
  
• if you click on the “-” in the right top of the viewer, you can hide the viewer. If you want it to appear again, then you have to click on the “+” on the right bottom of the page.

Conclusion

With this Chrome like indexedDBViewer you can inspect the structure of your database inclusive all data stored within it. This with the advantage that it runs inside the browser, so you can use it cross-browser.

Linq2IndexedDB: Debugging IndexedDB

In my latest version of the Linq2IndexedDB 1.0.7, I added the viewer object. This object allows you to inspect your IndexedDB database and gives you an overview of all the object stores and indexes that are present. It even gives you details about how they are configured and what data they contain. Also using this, you can take a look at your database in various debugging tools like:

• Google Chrome Developer tools
• Firefox Developer tools
• IE Developer tools
• Visual Studio

The viewer object contains 4 properties:

1. configuration: In here you will find the way the Linq2IndexedDB framework is configured. (The same properties as you can define in the configuration object are present +  a property indicating if framework is running in auto create mode.)
2. name: The name of the IndexedDB database
3. objectStores: A collection of all the object stores that are present in the database
4. version: The current version of the database

Inside an object store object, we can see the following:

1. autoIncrement: indicates if the keys for the object store are generated by the IndexedDB API
2. data: A collection of all the data available in the object store. These data objects are shown as key/value pair objects.
3. indexes: A collection of all the indexes available on the object store.
4. keyPath: The property inside the object that keeps the key
5. name: The name of the object store

The last level we can take a look at, are the indexes. The following information will be provided:

1. data: A collection of all the data available in the object store. These data objects are shown as key/value pair objects.
2. keyPath: The property inside the object that keeps the key
3. multiEntry: Determines if a key is only once defined in the index (which means the value keeps an array of all the values in the object store who match) or the key can be present multiple times (once for every value that matches in the object store.)
4. name: The name of the index

conclusion

I hope this debugging information can help you speed up your software development and finding bugs while working with the IndexedDB API. The latest version of the framework can be found on codeplex, nuget and MyGet.

Update 28/07/2012

I added a new version of the framework, because there were some little bugs with the viewer. The following things change:

• The viewer no longer blocks the deletion or upgrade of the database
• The viewer now gets updated when the structure of the database changes
• The viewer is default disabled for performance issues. If you want to enable it, add true as 3th argument on the function to create a linq2indexeddb function

   1: var db = $.linq2indexedDB("test", null, true);

Linq2IndexedDB: Release 1.0.3

This weekend I released a new version of the Linq2IndexedDB. The major changes in this release is a broader support of browsers. Because of the release of a new version of the IndexedDB spec some changes were made. The biggest change of them all is the transactionType. In previous versions this was a number (READ_ONLY = 0, READ_WRITE = 1, VERSION_CHANGE = 2), but this has changed into string values (“readonly”, “readwrite”, “versionchange”). Also these values aren’t available any more under the IDBTransaction interface.

Since this release the Linq2IndexedDB library now also supports browsers that doesn’t implement the IndexedDB specification yet. The only condition is they support the obsolete WebSQL spec. This means that Opera and Safari are now supported by the Linq2IndexedDB due the IndexedDB shim written by nparashuram who is also a contributor to the Linq2IndexedDB project.

With the release of the Windows 8 Release Preview, a new version of Internet Explorer 10 was released. Next to the change I described in the beginning of this post, IE10 Release Preview now uses the window.indexeddb implementation and no longer uses the ms prefix (window.msIndexedDB). The only disadvantage is they do not implement the autoIncrement and multiEntry attribute yet.

Next to the changes made to the Linq2IndexedDB library, I’ve started building on a new project: an IndexedDBViewer. This allows you easy access to the database structure and the contents of the object stores. The only thing you need to provide is the name of the IndexedDB you want to inspect. The only thing you need to keep in mind is that this IndexedDB viewer must be added to the Web app. This is necessary because you can only access the IndexedDB databases defined within your origin (domain).

All these changes are now available on MyGet:

• Linq2IndexedDB (jQuery) + IndexedDBViewer
• Linq2IndexedDB (Windows 8 implementation, uses WinJS Promises)

and on NuGet:

• Linq2indexedDB (jQuery)
• Linq2IndexedDB (Windows 8 implementation)
• IndexedDBViewer

All the sources of these projects can be found on CodePlex.

Using LINQ to Indexed DB

While the library is still under development, I want to take some time to explain how you can use this framework, and show how easy it gets to work with the Indexed DB. As mentioned before, the library is based on the on the Promises context. This way we can easily handle all the async callbacks on which the Indexed DB API is based, and provide a uniform object to the developer for handling the results and/or errors. And by using the progress callback, we can provide returning multiple records one by one instead of a whole collection in the complete callback. For more information about promises:

• jQuery promise
• WinJS promise

Another strength of the library is, that you get the opportunity to let it auto build it’s structure. It’s not necessary to provide the database structure. You can just start writing queries, and the library will take care of the creation of tables and indexes. This way it can easily be used for writing POCs or demo applications. This means when ever you are mentioning a string value in the from method that isn’t known in the object store collection, it will be created for you.

But enough about the theory, let us watch some code.

Setting UP Linq2indexeddb

The first thing you need to do is getting the linq2indexeddb library. You can do this by getting the JS script files from codeplex. The only thing you need to make sure is: the sort.js and where.js file need to be in a “Script” folder under the root of the project. These files are used to preform web worker tasks and are hardcoded referenced for now.

Or VS developers can use Nuget Packages:

• http://www.myget.org/feed/Packages/linq2indexeddb (jQuery version)
• http://www.myget.org/feed/Packages/linq2indexeddbmetro (Win8 version, using WinJS)

Once you have the linq2indexeddb library, the next thing you need to do is adding a reference to it in your page. Note, if you are using the jQuery version, you need to add a reference to the jQuery framework first.

using Linq2indexeddb

Once all the references are added, we can start using the library. The first thing you need to do is creating a instance of the linq2indexeddb object. You can do this by calling the linq2indexeddb method on the window object. This method accepts 3 parameters:

• The first one is the name of the database u want to use.
• The second one is a database configuration object. More on that later on the post.
• The last is an Boolean which allows you to enable logging. By default this is disabled

   1: var db = window.linq2indexedDB("dbName", dbConfig, false);

Configuring the database

When opening/creating the database, you can provide a database configuration. Here you can configure the object stores and indexes you want to use. There are several ways to do the configuration, but one thing needs to be provided at all time: the version of the database. This makes sure that the database will have the correct structure we need.

   1: var dbConfig = {};

   2: dbConfig.version = 1;

A second thing we need to do, is providing a way to define the structure. In the current implementation of the library, there are 4 ways to do this. For now I would advise you to use the definition. This doesn’t require you to write the create/delete statements your self. But if you do want to, you can make use of the promises present in the linq2indexeddb.core to create/delete object stores and indexes.

onupgradeneeded

This a function that gets called when the database needs to get updated to the most recent version you provided in the configuration object. 3 parameters are passed to this function:

• Transaction: on this transaction you can create/delete object stores and indexes
  
• The current version of the database
  
• The version the database is upgrading to.

   1: dbConfig.onupgradeneeded = 

   2:     function (transaction, oldVersion, newVersion){

   3:         // Code to upgrade the db structure

   4:     }

The onupgradeneeded callback is the only one that can’t be used in combination with one of the other ways to define the function

schema

The schema is an object which defines the several versions as a key/value. The key keeps the version it targets and in the value an upgrade function. In this function you can add your code to upgrade the database to the version given in the key. The upgrade function has one parameter:

• Transaction: on this transaction you can create/delete object stores and indexes

   1: dbConfig.schema = {

   2:     1: function (transaction){

   3:             // Code to upgrade the db structure to version 1

   4:        }

   5:     2: function (transaction){

   6:             // Code to upgrade the db structure to version 2

   7:        }

   8: }

Note: If the database needs to upgrade from version 0 to 2, the upgrade function of version 1 gets called first. When the upgrade to version 1 is done, the upgrade function of version 2 gets called.

definition

The definition object is the only way to define your database structure without having to write upgrade code. The object keeps a collection of objects which describe what needs to be added or removed for a version. Each object exists out of the following properties:

• Version: The version where for the definitions are.
  
• objectStores: Collection of objects that define an object store
  
  
  
  • name: the name of the object store
    
  • objectStoreOptions
    
    
    
    • autoincrement: defines if the key is handled by the database
      
    • keyPath: the name of the property that keeps the key for the object store
    
    
  • remove: indicates if the object store must be removed
  
  
• indexes: Collection of objects that define an index
  
  
  
  • objectStoreName: the name of the object store where the index needs to be created on
    
  • propertyName: the name of the property where for we want to add an index
    
  • indexOptions
    
    
    
    • unique: defines if the value of this property needs to be unique
      
    • multirow: Defines the way keys are handled that have an array value in the key
    
    
  • remove: indicates if the index must be removed
  
  
• defaultData: Collection of default data that needs to be added in the version
  
  
  
  • objectStoreName: the name of the object store where we want to add the data
    
  • data: the data we want to add
    
  • key: the key of the data
    
  • remove: indicates if the data needs to be removed

   1: dbConfig.definition= [{

   2:     version: 1,

   3:     objectStores: [{ name: "ObjectStoreName"

   4:                        , objectStoreOptions: { autoIncrement: false

   5:                                              , keyPath: "Id" } 

   6:                    }]

   7:     indexes: [{ objectStoreName: "ObjectStoreName"

   8:                   , propertyName: "PropertyName"

   9:                   , indexOptions: { unique: false, multirow: false } 

  10:               }],

  11:     defaultData: [{ objectStoreName: ObjectStoreName

  12:                       , data: { Id: 1, Description: "Description1" }

  13:                       , remove: false },

  14:                   { objectStoreName: ObjectStoreName

  15:                       , data: { Id: 2, Description: "Description2" }

  16:                       , remove: false },

  17:                   { objectStoreName: ObjectStoreName

  18:                         , data: { Id: 3, Description: "Description3" }

  19:                         , remove: false }]

  20: }];

onversionchange

This a function that gets called when the database needs to get updated to the most recent version you provided in the configuration object. But in contrast to the onupgradeneeded callback, this function can be called multiple times. For example if an database is upgrading from version 0 to version 2, the onversionchange will be called 2 times. Once for version 1 and once for version 2.  2 parameters are passed to the function:

• Transaction: on this transaction you can create/delete object stores and indexes
  
• The version of the database it is upgrading to.

   1: dbConfig.onversionchange = 

   2:     function (transaction, version){

   3:         // Code to upgrade the db structure

   4:     }

Querying data

Once the database structure is created, we can start querying on it. On the linq2indexeddb object we have a field linq which holds all the linq functionality. The first method you always need to call is the from method. This method excepts only one parameter, the name of the object store we want to work on. Once we have this we can start inserting, updating, deleting and selecting data from it.

   1: // inserting data, key is optional

   2: db.linq.from("objectstore").insert({}, key);

   3: // updating data, key is optional

   4: db.linq.from("objectstore").update({}, key);

   5: // removing data

   6: db.linq.from("objectstore").remove(id);

   7: // clears all data from the object store

   8: db.linq.from("objectstore").clear();

   9: // gets a single record by his key

  10: db.linq.from("objectstore").get(key);

  11: // selects all objects

  12: db.linq.from("objectstore").select();

But the library also provides ways to filter data. This can be done by calling the where method. This accepts the name of the property we want to filter on as parameter. On this you can call the filter you want to add. For now these are limited to the following:

• equals(value)
  
• between(value1, value2, value1included, value2included)
  
• greaterThen(value, valueIncluded)
  
• smallerThen(value, valueIncluded)
  
• inArray(arrayOfObjects)
  
• like(value)

So if we want to select all the objects which have a field called '”property” and have the value “value” we write the following query:

   1: db.linq.from("objectstore").where("property").equals("value").select()

If you want to add multiple filters you need to do the following:

   1: db.linq.from("objectstore")

   2:        .where("property").equals("value")

   3:        .and("anotherproperty").greaterThen(4)

   4:        .select()

You are also able to sort your data:

• orderBy(propertyName)


• orderByDesc(propertyName)

   1: db.linq.orderBy("property").select()

As last, the library also enables you to get only a subset of the properties stored in the objects

   1: db.linq.from("objectstore").select(["property1", "property2"])

Conclusion

This was a brief introduction of the functionalities of the linq2indexeddb library. In future post I will go more in-depth into the advanced functionalities like linq2indexeddb.core. If you have any suggestions, bugs, additions,… about the library, feel free to contact me. Hope you enjoy using the library.

LINQ to Indexed DB

Since I started experimenting with the Indexed DB API, I have been searching for a simple way to add, retrieve, change, … data. In the beginning I wrote a little framework that provided some methods to retrieve, add, … data without having to think how to setup a connection. For experimenting this was enough, but when I started to build some demo apps, I noticed a needed a more generic way to do my CRUD operations.

So I start searching the internet for frameworks around the Indexed DB API’s. One project I found very interesting. It was the one of nparashuram. He was started with a Linq 2 Indexed DB Framework. Everything was still very basic, but it was well structured. Also it was only compatible with Firefox and Chrome, but not with the IE prototype and IE 10. So I contacted nparashuram and we decided to keep working on it together.

The framework is based on promises. This way we can easily handle the async calls which the Indexed DB API uses. We also use it as return value of the query you make. This way you can easily decide whether you want to use the complete method or the on progress method when retrieving multiple records. Also I believe this will be a programming model which we will see more and more in the future. Certainly if we want responsive applications.

The framework takes away the complexity of opening a database, creating transactions, … the only thing you need to worry about is how to structure your database and how to query. It also provides a way of creating the database structure while querying. This way you don’t have to create object stores or define the structure. Just inserting data to an object store, the object store will be created if not present.

The code of the framework can be found on codeplex and works as an extension on the jQuery framework. If you have some feature request you can add them here. Or you can contact me if you have some questions about it.

Keep following my blog or codeplex for new features and samples on this framework.

Indexed DB: Defining the database structure

In previous post I have been talking about the basic concepts in the Indexed DB and how you can open/create a database and a database connection. Today I will tell you how you can construct your own database structure. This includes defining the object store where we can store our objects and defining indexes. These indexes will be used when searching into the objects we store in our database.

version_change transaction

There exists only one way to define your object stores and indexes, and this is in a VERSION_CHANGE transaction. We can start this transaction by calling the setVersion method on the database connection. When a database is initially created, the version of the database is an empty string. By passing a string as version to the setVersion method, we add object stores and indexes. This we do by defining the onsuccess event. We can also provide error handeling trough the onerror event.

var dbreq = dbConnection.setVersion(version);
dbreq.onsuccess = function (event) {
      // Here we put code to create object stores or indexes
}

dbreq.onerror = function (event) {
      // Here we put code to handle an error while changing the version
}

dbreq.onabort = function (event) {
      // Here we put code to handle an abort when changing the database version
}

If we are using the IE 9 Indexed DB prototype, we need to commit the transaction. In all other browsers this is not necessary because the implementation of Indexed DB determines that every transaction is committed by default when closed. If a transaction should be aborted you have to do this explicitly.

dbreq.onsuccess = function (event) {
       var txn;
       if (event.result) {
             txn = event.result;
       }
       // Here we put code to create object stores or indexes
      
       if(typeof(txn.commit) != "undefined")
       {
            txn.commit();
       }
}

Because a database can’t have multiple versions at one time, the only way you can change the version is by closing all other connections to the database. This also means no new connections can’t be opened until the VERSION_CHANGE transaction is completed. A blocked event will be raised when a connection to the database is still open when changing the version.

dbreq.onblocked = function (event) {
// Here we put code to handle an abort when changing the database version
}

Creating an objectStore

Once we started the VERSION_CHANGE transaction, we can start adding or deleting object stores. We can do this by calling the createObjectStore method. As first parameter we need to pass the name of the object store. Optionally you can can add two extra parameters. The first one is JSON object with two fields. The first field is a keyPath, when this is provided, the key of the object store will be determined by the field that has the name given in the string of the key path. The second field determines if the object store should have a key generator.

The last parameter we pass is the same as the autoIncrement field in the second parameter. We do this to enable the object store to have a key generator in the IE9 prototype. When using Firefox, Chrome and IE 10, you don’t need to pass this parameter.

The following combinations of a KeyPath and autoIncrement are possible:

Key path	Auto increment	Description
Empty	False	This object store can hold any kind of value, even primitive values like numbers and strings. You must supply a separate key argument whenever you want to add a new value to the object store.
Provided	False	This object store can only hold JavaScript objects. The objects must have a property with the same name as the key path.
Empty	True	This object store can hold any kind of value. The key is generated for you automatically, or you can supply a separate key argument if you want to use a specific key.
Provided	True	This object store can only hold JavaScript objects. Usually a key is generated and the value of the generated key is stored in the object in a property with the same name as the key path. However, if such a property already exists, the value of that property is used as key rather than generating a new key.

dbConnection.createObjectStore("ObjectStoreName"
                                              , { "keyPath": "keyPath"
                                                , "autoIncrement": true }
                                              , true);

removing an object store

When we want to remove an object store, the only thing we need to pass is the name of the object store we want to remove.

dbConnection.deleteObjectStore("ObjectStoreName");

Creating an INDEX

Once we created our object store, we can add indexes to it. These indexes are object stores as well, but the key of these key/value pairs is the key path of the index. This means that in this object store that multiple keys with the same value are allowed. When we want to create an index we need to provide a name and a key path for them. Optionally we can provide a JSON object with a unique and multiplerow field.

Field	Description	Support
unique	A boolean value indicating whether the index allows duplicate values. If this attribute is "true", duplicate values are not allowed. Duplicate values are allowed when this attribute is "false" (the default value). This means when you add an object to an object store where an index with a unique value on "true". You will get an exception when you add an object with a duplicate value in the field of the key path of the index.	IE 10 FF Chrome
multiplerow	A boolean value that describes determines the results when multiple rows in the object store match individual key values. When this happens, the resulting object is an array. If this parameter is "true", the resulting array contains a single item; the key of the item contains an array of the matching values. When this parameter is "false" (the default), the result array contains one item for each item that matches the key value.	IE 10

store.createIndex("IndexName"
                         , "keyPath"
                         , { unique: false });

If we want to create an index in IE 9 Indexed DB prototype, we need to pass the boolean value for the uniqueness as parameter and not as a JSON object.

store.createIndex("IndexName"
, "keyPath"
, false);

Deleting an index

The last action we can do in the VERSION_CHANGE event is deleting an existing index. We can do this by passing the name of the index we want to delete.

store.deleteIndex("IndexName");

Indexed DB: Creating, opening and deleting a database

In my last post I provided some more information about the structure of the Indexed DB database. Today, I will dive into code and tell you how to create, open and delete a database. There are some small differences between the browsers, but I will handle that at the specific parts of code.

The code I will show will be the Asynchronous implementation of the API. In my previous post I have said no browser does implement the synchronous API, but I was wrong. The IE 10 Preview 3 also implements the Synchronous implementation, but you should only use it in combination with web workers, because it freezes the UI if you don’t.

Initializing the Indexed DB API

First things first: the Indexed DB API is still in draft, so this means the unified Indexed DB property on the window element isn’t implemented yet. Every browser uses his on prefix to use the API, but we can assign this to the Indexed DB property. This gives us a way to us the Indexed DB on the same way.

Initializing the Firefox implementation

if (window.mozIndexedDB) {
            window.indexedDB = window.mozIndexedDB;
            window.IDBKeyRange = window.IDBKeyRange;
            window.IDBTransaction = window.IDBTransaction;
}

Initializing the Chrome implementation

if (window.webkitIndexedDB) {
            window.indexedDB = window.webkitIndexedDB;
            window.IDBKeyRange = window.webkitIDBKeyRange;
            window.IDBTransaction = window.webkitIDBTransaction;
}

Initializing the IE 10 Preview 3 implementation (You’ll need to be running the Windows 8 Developer Preview to run this)

if (window.msIndexedDB) {
            window.indexedDB = window.msIndexedDB;
}

Initializing the IE prototype implementation

if (navigator.appName == 'Microsoft Internet Explorer') {
            window.indexedDB = new ActiveXObject("SQLCE.Factory.4.0");
            window.indexedDBSync = new ActiveXObject("SQLCE.FactorySync.4.0");

            if (window.JSON) {
                window.indexedDB.json = window.JSON;
                window.indexedDBSync.json = window.JSON;
            } else {
                var jsonObject = {
                    parse: function (txt) {
                        if (txt === "[]") return [];
                        if (txt === "{}") return {};
                        throw { message: "Unrecognized JSON to parse: " + txt };
                    }
                };
                window.indexedDB.json = jsonObject;
                window.indexedDBSync.json = jsonObject;

            }

            // Add some interface-level constants and methods.
            window.IDBDatabaseException = {
                UNKNOWN_ERR: 0,
                NON_TRANSIENT_ERR: 1,
                NOT_FOUND_ERR: 2,
                CONSTRAINT_ERR: 3,
                DATA_ERR: 4,
                NOT_ALLOWED_ERR: 5,
                SERIAL_ERR: 11,
                RECOVERABLE_ERR: 21,
                TRANSIENT_ERR: 31,
                TIMEOUT_ERR: 32,
                DEADLOCK_ERR: 33
            };

            window.IDBKeyRange = {
                SINGLE: 0,
                LEFT_OPEN: 1,
                RIGHT_OPEN: 2,
                LEFT_BOUND: 4,
                RIGHT_BOUND: 8
            };

            window.IDBRequest = {
                INITIAL: 0,
                LOADING: 1,
                DONE: 2
            };

            window.IDBTransaction = {
                READ_ONLY: 0,
                READ_WRITE: 1,
                VERSION_CHANGE: 2
            };

            window.IDBKeyRange.only = function (value) {
                return window.indexedDB.range.only(value);
            };

            window.IDBKeyRange.leftBound = function (bound, open) {
                return window.indexedDB.range.leftBound(bound, open);
            };

            window.IDBKeyRange.rightBound = function (bound, open) {
                return window.indexedDB.range.rightBound(bound, open);
            };

            window.IDBKeyRange.bound = function (left, right, openLeft, openRight) {
                return window.indexedDB.range.bound(left, right, openLeft, openRight);
            };
}

Creating and opening a database

Once we have our Indexed DB initialized, we can start the real thing. Creating a database. There is no specific method to create a new database, but when we call the open method, a database will be created if it doesn’t exists. After that a connection to the database will be opened. To open or create a database, the only thing you need is a name.

var dbreq = window.indexedDB.open(“database name”);

dbreq.onsuccess = function (event) {
        var dbConnection;
        // IE prototype Implementation
        if (event.result) {
                dbConnection = event.result;
        }
        //IE 10 Preview 3, Firefox & Chrome implementation
        else {
                dbConnection = dbreq.result;
        }
}

dbreq.onerror = function (event) {
       // Log or show the error message
}

Calling the open method, will return an IDBRequest object. On this object we can attach an onerror function and an onsuccess function. The onerror event will provide handling the error returned by the open function, here you can provide logging or error handling. In the onsuccess event, the database connection will be opened. We can now start using the database connection.

As you can see in code, IE prototype implementation is handling this on an other way then IE 10 Preview 3, Firefox and Chrome. In the IE prototype implementation we get the result (the database connection) out the parameter that is passed trough with the onsuccess function. For IE 10 Preview 3, Firefox and Chrome, we get the result from the IDBRequest object. This is the implementation that was defined by the W3C.

Deleting a database

Deleting the database will happen almost the same way as opening a database. You provide the name of the database you want to delete, and the database will get deleted. The error event will only be called when something goes wrong. Providing a database name that doesn’t exists, will not result in an error and the onsuccess function will get called.

var dbreq = window.indexedDB.deleteDatabase(“database name”);
        dbreq.onsuccess = function (event) {
             // Database deleted
        }
        dbreq.onerror = function (event) {
            // Log or show the error message
        }

Now we can create, open and delete a database. In one of my next posts, I will show you how you can create/change your database structure.

New features of IE10

With the release of the Windows 8 Developer preview on Wednesday at the BUILD conference, the third preview of IE10 was released. I had never expected that this would bring that many new features. Some of the features were already available at the html5labs, but needed sever installations to get it work. But from now all these features are released in the new preview of IE10. Even features who weren't available at html5labs are added.

From now it will be possible to build web applications that will work online as well offline. The API for this is the HTML Application Cache. In a manifest file you describe all the resources (HTML files, JS files, CSS files, Images, …) you need to let your application work offline. For storing your data offline, we now have 2 possibilities. We have the Local storage we can use to save key/value pairs. This is handy if we save small amounts of data and do not need a structured way to be saved or need to query on data in the value. The second possibility is the use of IndexedDB. This is an offline database that runs in the client. You can’t use SQL to query on it, but it has a set of interfaces that provide methods to create, read, update and delete your data and structure.

Another feature that was available at html5labs was web sockets. Web sockets enable you to use TCP to communicate between your browser and the webserver. On this way we can save a lot of traffic when build applications who need frequent polling to get there data. When using HTTP we are always sending an HTTP header. In a web socket message we send only add 0x00 at the begin of the message and 0xFF at the end.

With the history API we will be able to manipulate the URL without having a page refresh or navigation. This way we can use AJAX to give the user a fluent way to work with your application (without page refresh) and adjust the URL at the same time. This enables the user to move back and forward in your web application who uses AJAX.

To improve the performance of your web applications, IE added the possibility to run scripts Asynchronously and the use of Web workers to make your web application multithreaded in your browser.

The File API provides the web developers a secure way to access files on the local machine. This way the user can manipulate local files without having to upload it to the server.

Other improvements are:

• Rich Visual Effects: CSS Text Shadow, CSS 3D Transforms, CSS3 Transitions and Animations, CSS3 Gradient, SVG Filter Effects
• Sophisticated Page Layouts: CSS3 for publication quality page layouts and application UI (CSS3 grid, flexbox, multi-column, positioned floats, regions, and hyphenation), HTML5 Forms, input controls, and validation
• Enhanced Web Programming Model: Better offline applications through local storage with IndexedDB and the HTML5 Application Cache; Web Sockets, HTML5 History, Async scripts, HTML5 File APIs, HTML5 Drag-drop, HTML5 Sandboxing, Web workers, ES5 Strict mode support.