The uses of a clientside database
Clientside data storage is no longer the exception, but rather the rule, and not just in native mobile applications and thick clients, but also in HTML5 web applications. The traditional use for a clientside database is to store user preferences, settings, various local data that the web application needs to remember such as favorites lists and shopping carts.
This is still very much needed, but another use is becoming more and more prevalent as clients become smarter and more powerful. You might want to offload server data to the client, which will have the double benefit of making user experience snappier and more responsive, and reducing the server workload, possibly saving you on bandwith and hosting. Many cloud services are billed per request or by data served, so offloading data to the client and saving on requests will directly translate to saving in costs.
Eg. as an e-newspaper, you might want to cache the entire issue on the client, with all articles, images, navigation and metadata. That way, the user will be able to flick between articles with the ease of traditional printed paper, and your servers will also be shielded from repeated requests to the same resources.
The JayData added value
The native API of IndexedDb is extremely cumbersome to the point of being atrocious, with an extremely limited set of query expressions allowed, and an asynchronous-per-record read mechanism. JayData will help you overcome at least part of the problems posed by IndexedDb, and allow you to handle data in a more streamlined way.
This is a context instantiation statement using the IndexedDb provider:
Similarly to the WebSQL provider, the parameter databaseName means exactly what it says.
The IndexedDb provider also takes a numeric version parameter, which allows you to handle schema changes – contrary to the SQLite / WebSQL providers, these are not autodetected. This is an internal and intentional limitation of IndexedDb itself.
The way to act on schema version changes is determined by the dbCreation parameter, which takes the following values:
- DropTableIfChanged: The IndexedDB database is dropped if it exists but JayData detects any change (added, removed or modified) in the key properties of the data model. This behavior is different for WebSQL – WebSQL DB is dropped if JayData detects any change in the data model.
- DropAllExistingTables: This option is primarily useful for testing, it recreates the datastore from scratch each time the program is run.
While IndexedDb is fully usable for storing and retrieving records, currently it supports filtering by loading the records into an InMemoryProvider context for data crunching, which might allow you to reuse the JSLQ expressions.
Of course support for projection and paging operations will be added in later versions, but we must note that the inherent capabilities of IndexedDb are far below those of either WebSQL or OData, and thus this provider will probably never have the same richness of features as those.
Note: the namespace of DbCreationType has been changed, now it can be found in $data.storageProviders namespace, not under $data.types.storageProviders.webSql or indexedDb. We changed the namespace to provide cleaner, provider-independent API.
IndexedDB Provider Pro
In case your app will manage thousands of records and you want to opimize the performance with indices or you want to use IndexedDB with transactions, give a try to JayData IndexedDB Provider Pro – more info