I am in the R&D phase of developing an application, with the following key requirements:
HTML5 web application - which will also have a hybrid version
Forms data will be stored locally, when no Internet connection
I cannot use web storage due to quota limitations - I am comparing SQLite and Indexed DB.
SQLite seems to be best fit, but it is deprecated
Indexed DB is a good alternative, but there's no Safari support - A hybrid application is supposed to be run on the iPad and on an Android device in the future.
I am confused in the selection of API. Is there some other alternative to SQLite or support of Indexed DB expected on Safari?
First of all, the one that has been deprecated by W3C is WebSQL not SQLite
IndexedDB -
It is incompatible with many types of mobile OS and is only compatible with certain types of versions of mobile OS
Developers cannot use SQL with IndexedDB. They can with SQLite and WebSQL
Most developers actively avoid using IndexedDB as much as they can
WebSQL -
It has been deprecated by W3C which means it is no longer maintained or developed
It requires another plugin called Polyfill to enable mobile applications to work with popular mobile OS such as Google Android and Apple iOS
SQLite -
It received an award from Google
SQLite has its official website. IndexedDB and WebSQL do not
On Google, SQLite returns 4.3 million results. WebSQL returns a bit less than 700K results and IndexedDB returns 282K results.
If you want a quick tutorial on SQLite,
Storage of SQLite database using Android and Phonegap
I think abandoning IndexedDB would be a bad idea, because it's probably the format of the future, so Safari might stop supporting WebSQL.
It appears there are various JavaScript solutions to bridge the gap between the two - saving in whichever is available on the user's browser:
JavaScript Library to Bridge IndexedDB and WebSQL
I think this is probably your best solution.
Yes, IndexedDB API is great and all browsers will support in near future.
I definitely recommend my own solution https://bitbucket.org/ytkyaw/ydn-db it is very thin wrapper for IndexedDB and fall back to Sqlite for safari.
IndexedDB is most likely the supported database of the future and it would be best to go with that instead of WebSQL. As Raymond pointed, it is best to refer to http://www.caniuse.com to see the current/future support in both desktop and mobile browsers.
Depending on the current needs of your solution, you might be fine with one of the many JavaScript libraries that are available which use the local storage and provide a query interface. One of the libraries, which has worked well for me is Lawnchair.
If you don't want to choose between IndexedDB or WebSQL you can use the Javascript library PouchDB.
I use it in an Android Webview to store offline data and it works pretty well. The data are stored on a local database (using IndexedDB or WebSQL) if there is no internet connection available and is synchronized with a remote database (CouchDB database) when there is an available connection.
PouchDB will depend on IndexedDB but fall back to WebSQL if IndexedDB is not supported. There is also the possibility to use a SQLite plugin for Cordova/PhoneGap.
I wanted to make a small edit to update this question, as google is directing to us to this question if you make a research on the subject of websql, localStorage and indexedDB. The edit was rejected, so I'm posting as a answer.
As others stated in their answers, IndexedDB lacked a bit before on support and on content on the web for it's documentation and specification.
But IndexedDB support has been vastly improved for mobile. It improved so much that the only browser who has no support or whatsoever, is Opera Mini, but it has only 0,34% of market usage.
As of 2015, I would suggest any developer to move to IndexedDB, as WebSQL has been deprecated and IE and Firefox stopped supporting it (that's more than 15% of market usage for these alone!) and SQLite is losing space rapidly to IndexedDB, which have now really good documentation sources, many. Some official as well!. Some IT companies are even motivating usage as well, like IBM.
I'm going to use it, and I have not met any problems so far. Safari has added support to it, and all major browsers as well. Go for it!
EDIT: A personnal addendum: I tried IndexedDB. I'm a Senior on my team, and IndexedDB syntax is just too messy and complex for small storage problems - I ended using localstorage to save some simple JSON data and parsing it when I need it. Way better for anyone on my team to get it (Me as well, of course!)
This may be late to the game, but you could look at: SequelSphere
It is a 100% HTML5/JavaScript Relational Database that works cross-browser and uses local storage to persist it's data. You can use SQL to query it as well. It is it's own database engine, and doesn't rely upon the built-in (WebSQL) relational databases. As such, it will work across all browsers.
While it currently only supports localStorage, the idea is to support all the standards going forward. As browsers support other types of persistence, SequelSphere would take advantage of that. The positive is that you only code against SequelSphere using standard SQL, and let it handle the persistence.
Nevertheless, be aware that it is a new product to the market, so that comes with both positives and negatives.
As other have pointed out, since this question has been asked, webSQL has been deprecated, while IndexedDB implementations now exist in all of the major browser vendors.
So to anyone who may find themselves here faced with the same decision to make, go with IndexedDB.
Others here have also implied, correctly, that a choice doesn't have to be made between the two types of databases. One can simply choose (or make) a library which utilizes whichever database is available on a client machine.
Check out BakedGoods if you're looking for such a library. It establishes a uniform interface that can be used to conduct storage operations in all native, and some non-native client storage facilities. It also maintains the flexibility and options afforded to the user by each.
With it, conducting storage operations in whichever of the database types is supported is a matter of...
... specifying the appropriate operation options and equivalent configs for both database types:
//If the operation is a set(), and the referenced structures
//don't exist, they will be created automatically.
var webSQLOptionsObj = {
databaseName: "Example_DB",
databaseDisplayName: "Example DB",
databaseVersion: "",
estimatedDatabaseSize: 1024 * 1024,
tableData: {
name: "Main",
keyColumnName: "lastName",
columnDefinitions: "(lastName TEXT PRIMARY KEY, firstName TEXT)"
},
tableIndexDataArray: [name: "First_Name_Index", columnNames: "(firstName)"]
};
var indexedDBOptionsObj = {
databaseName: "Example_DB",
databaseVersion: 1,
objectStoreData: {
name: "Main",
keyPath: lastName,
autoIncrement: false
},
objectStoreIndexDataArray: [
{name: "First_Name_Index", keyPath: "firstName", unique: false, multiEntry: false}
],
};
var optionsObj = {
conductDisjointly: false,
webSQL: webSQLOptionsObj,
indexedDB: indexedDBOptionsObj
};
... and conducting the operation:
bakedGoods.set({
data: [
{value: {lastName: "Obama", firstName: "Barack"}},
{value: {lastName: "Biden", firstName: "Joe"}}
],
storageTypes: ["indexedDB", "webSQL"],
options: optionsObj,
complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});
Its simple interface and unmatched storage facility support comes at the cost of lack of support for some storage facility-specific configurations. For instance, it does not support the conduction of storage operations in WebSQL tables with multi-column primary keys.
So if you make heavy use of those types of features, you may want to look elsewhere.
Oh, and for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .
I had a doubt regarding HTML5 storage technologies like WebSQL, WebStorage/LocalStorage, and indexedDB and to a lesser extent appCache.
Considering the case of chrome (my default browser), these stores are maintained in chrome browser's own directory. Do they impact the starting-up time of the browser?
A colleague has said to experience browser slowing down or behaving in sluggish manner when a larger amount of data is stored.
Couldn't find references to how these technologies impact the browser working, so would love if any fellow-stacker could guide me.
Be careful : the WebSQL API is dead (it was based on sqlite instead of a generic API and so was judged not desirable by the Mozilla team, the Indexed Database API will be used instead but you should probably wait for it to be more supported).
LocalStorage is fine, I use it in all my web applications without problems nor measurable boot time. But keep it for parameters, preferences, and so on, as the only reliable storage is always server side. The local storage can be removed, lost, modified, not readable for many reasons (user uses another browser or computer for example). And it seems to me that a big local storage is a burden to the user and thus not very correct (which is probably the reason why this size is limited).
BTW, there is no reason a reasonnable local storage could slow in a measurable manner the launching of a browser.
I agree with dystroy; Normally the local storing is harmless if done the right way. Storing MASSIVE amounts of data in the browser on the other hand is quite discouraged. It won't slow down the browser performance overall but will slow down the web app using it (as far as I know, Chrome fetches the local storage values dynamically when the 'owner app' is called).
I have to build (obviously using flex) an AIR application that must be linked to a given hardware (i.e. hard-disk), so it can't be copied elsewhere..
Usually using others languages, every time you open the application, a comparison between HardDisk or CPU ID and the value stored in the application itself...
Using Flex this is not possible (as far as I know)...
User/Password check obviously won't work..
I can't use a webservice, the application needs to work offline too..
How could I do?
With AIR you can integrate native apps - either indirectly (start a process and get its result) or directly (as a library).
Any of these techniques allow you to achieve your goal the same way you would in the case you described as "other languages"... BUT BEWARE: this makes your app platform-dependent AND can potentially lead to problems since it is prone to permissions issues etc.
Another point: no such technique is 100% secure (can be circumvented AND can lead to unsatisfied legitimate users!) - so you should really consider whether this is the way to go...
How do I setup the basic switching of offline storage modes (offline/online) in Web SQL? I know there's javascript
window.navigator.onLine. I can check the mode and then go through a process...
//All GET/POST performed with AJAX
//On Startup pulldown entire accessible database into offline storage (Doesn't seem secure IMO)
//if(read) pull from offline
//if(create, update, delete and online) pull from standard db, mark changes with offline expiration flag
//if(create, update, delete and offline) perform operation on offline storage, persist with POST when next online (change flag)
I'm asking if there is any OOB integration for these standard tasks?
The navigator.online property generally isn't very useful - in a desktop browser all it does is hook into the File -> Work Offline menu. It may be more useful on an iPad, I don't know because I don't have one, and I'm guessing there's not a File menu, but I would recommend you test.
A common approach to this issue is to set up two easily distinguishable files in the fallback section of your manifest. Every time you want to connect back to the server attempt to fetch the file with AJAX and, in the callback, check it to see if you got the online file or the fallback, then branch accordingly.
You shouldn't be using Web SQL as that spec was nixed a new months ago. You should be using Localstorage. Unless you are specifically coding for something like the iphone, but even then you dont know how long the spec will be in webkit.
I have some questions concerning the abilities of client storage in HTML5. From what I've found so far there are three different possibilities:
WebSQLDatabase: Supports client site SQL-Tables, which are stored in a SQLite Database. This standard is discontinued. Does this mean that browsers that currently support this will drop this support in the future?
WebStorage and IndexedDB seems quite similar to me. They both offer key/value-store capabilities. Where is the difference?
WebSQLDatabase: Does this mean that browsers that currently support this will drop this support in the future?
Ans: After looking at this post, it seems like safari put this work on hold, as they have stopped comments and ping backs. Also refer to this and this, Chrome will surely put current api in deprecated status. In future versions, once IndexedDB API completely implemented, they may drop the support.
WebStorage and IndexedDB.. Where is the difference?
Ans: WebStorage has some storage mechanisms like sessionStorage, localStorage etc. each has key/value pair like storage. localStorage is of HTML5 feature which uses SQLite database, but with one table and two fields (key and value).
Whereas using IndexedDB you can create the number of databases with number of tables..
WebSQLDatabase has been dropped because of the main security issue. e.g. cross-origin attack. see