Trying to write a website/webapp , should work both on desktop and mobile.
I will need a client side database support, but could not find a solution that would work both for popular browsers (FF/IE) and also on iOS.
It states everywhere that I should either go for IndexedDB or Web SQL - but I want full support and I don't want to use two databases depending on the client machine.
I know this question might be duplicated, but I could not find an answer with a reliable substitute for the IndexedDB - Web SQL solutions.
Any advice ?
The database should store a lot of textual data and should also textual search.
You can go with IndexedDB way with using IndexedDBShim (a polyfill for WebSQL, it works well on iOS devices ) as well. IndexedDB has a decent support now in both desktop and mobile browsers.
For storage quota, notice that IOS devices allows maximum of 50 MB storage, whereas on other browsers there is no hard limit.
IndexedDB doesn't have any free text search API. You need to build it on your own, or look at this library YDN-DB. This may prove helpful for you !!
I am currently looking to write a web app in HTML5. It is my first HTML5 web app.
The main feature of this app is its offline feature. When I mean offline, it will be something like C:\APP\index.html (for Windows ), and it will be the same thing for Mac. So with that said, I have been looking into LocalStorage, WebSQL, IndexedDB.
And I come to this conclusion that LocalStorage is not going to be good enough for the web app that I am going to write. The IndexedDB only for all the major browsers except safari. Safari (desktop & iOS) supports WebSQL not IndexedDB. And then I found out that WebSQL is not going to be supported.
So I am wondering if there is a "universal" solution to my dilemma? Or Should I have code IndexedDB and WebSQL so that it will work on all the browsers? Any suggestions are welcome.
Your app is the only thing that needs to be accessing the data it stores, right? If so, data is data is data, and as long as you include everything you need to read, write to, and understand the information your data encodes, it doesn't matter one bit (no pun intended) what format you use to store it. Whatever language you are using to create the app, it will have library functions that can manipulate stored data.
If worst comes to worst, you can always go with the lowest common denominator and use a raw binary or text file; those are the only true universal formats.
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 :) .
What are my alternatives to localStorage for persisting key/value pairs on the client? Ideally I'm looking for something that the user can't inadvertently delete (as they theoretically could with localStorage).
With HTML5 your local storage options are limited to the following:
localStorage
cookies
Web SQL (in WebKit and Opera)
IndexedDB (in all modern decent browsers)
… however, users can delete data in any of these stores, and that is as it should be.
An alternative could also be localForage, a js library that provides the ease of use of localStorage with all the advanced features of IndexedDB.
One of the benefits: you don’t have to convert your data structures to JSON in order to save them in the datastore.
Its API has support for ECMAScript 6 Promises, which provide a better way of handling asynchronous code.
Unfortunately it doesn’t work well with any IE under 11.
While there are a lot of good stuff about html5, one thing I don't get is the redondant storage mechanism, first there is localstorage and sessionstorage, which are key value stores, one is for one instance of the app ("one tab"), and the other works for all the instances of that application so they can share data. Both are saved when you close your browser and have a limited size (usually 5MB), that's great and everything would be nice if we stopped there.
But then there is the "Web SQL Database", which has the same security system as the localstorage, the same size limit, the same everything except it works like/is sqlite, with tables and sql syntax and all of that.
And the bummer is, they don't work on the same data at all ! This is not two way to access your data, this is really two storage for every html 5 app out there (not created by default yes, but still you see my point).
What I would like to know is, is there a reason for both of this mechanisms to exist at the same time ? Or did they just look at sql and nosql movement to pick the best then went "screw it let's add both !" ? Why not implement local/session storage as a table inside web sql db ?
My take is that localstorage is a proper rewrite of the way cookies should have been done in the first place. It has a very simple api and low barrier to adoption.
Web SQL is pretty heavy duty and would be a serious pain for saving just a simple value so they have very different use cases. localstorage is actually implemented in WebKit using SQLite but just not exposed via WebSQL.
Session storage cannot be implemented easily inside the database as it is effectively in global scope and you don't want the data visible to other tabs. Because it is transient data you wouldn't typically want to store lots anyway so wouldn't need transaction and querying.
See also:
http://www.pubbs.net/200904/webkit/28373-webkit-dev-need-help-making-windowlocalstorage-span-processes.html
I asked myself the same question, and here is the answer, quoted from the Chromium wiki :
Q: Why this over LocalStorage?
A: LocalStorage is inherently racy or a
parallelism disaster, depending on
whether or not you're willing to
implement the "storage mutex"
described in the spec. Chromium has
decided not to implement it. WebKit
itself is single thread/process (i.e.
no parallelism period)
Source :
http://www.chromium.org/developers/design-documents/indexeddb
Web SQL can be useful if you want to copy the structure of your database locally for offline use.
But Web SQL will not be implemented in firefox :
http://us1.campaign-archive.com/?u=168bf22f976f5a68fe5770d19&id=6c2d73c957#standards
Mozilla, Microsoft and Oracle are working on the "IndexedDB" alternative : http://www.w3.org/TR/IndexedDB/
Work in progress in firefox : https://wiki.mozilla.org/Firefox/Projects/IndexedDB
Storage demos :
A good article from PPK about html5 storage : http://www.quirksmode.org/blog/archives/2009/06/html5_storage_t.html
Ian Hickson early 2008 session storage
demo :
http://www.whatwg.org/demos/2008-sept/wizard/step1.html