CODEWITHSUNDEEP
google-chromeweb-sqlindexeddb
Sanuj
Sanuj

Reputation: 1147

HTML 5 web SQL chrome support , Should I use webSQL?

Here I have to make a server based application which will run on an closed network and specific to chrome. I have to decided now whether I should use WebSQL (Which will definitely saves us development time) or should we use IndexedDB (of which we do not have much knowledge).

How can I find out that chrome will continue to support WebSQL in feature versions? Or I have to restrict my client limited to supporting version, which is not good for a long term business relationship.

Please Also tell me any nice tutorial or guide for learning Indexed DB ...

And I couldn't understood the the reason w3c stopped supporting webSQL. Do anyone know??

Upvotes: 0

Views: 1952

Answers (3)

Kevin
Kevin

Reputation: 2697

I'm a couple of years late, but thought it would be helpful to answer those of OPs questions which have not been directly answered, as well as add some helpful suggestions :) .

How can I find out that chrome will continue to support WebSQL in feature versions?

As far as I know, there is no way to determine when a given browser vendor will drop support of a technology or API. However, it is customary for the vendors to notify developers some time (on the order of months or years) before they are to do so.

Should I use webSQL?

In short, no. Since Deni Spasovski's answer, everything concerning the deprecation of WebSQL still stands. IndexedDB on the other hand, enjoys the support of all of the major browser vendors. So go with the latter.

I should point out, howver, that a decision between the two databases isn't one that necessarily has to be made; one can simply choose (or make) a library which utilizes whichever database is available on a client machine.

BakedGoods differs from such libraries already suggested here in several ways; most pertinently, it allows the storage type(s) that are to be utilized to be explicitly specified, in turn allowing the developer to introduce other factors (such as performance characteristics) in to the decision-making process.

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 yours truly :) .

Upvotes: 0

Deni Spasovski
Deni Spasovski

Reputation: 4129

WebSql is no longer a maintained standard by W3C since 18 November 2010

This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.

Here is a link to github project which i maintain and has examples of the basic functions of IndexedDB such as: creating db, inserting, retrieving, updating and deleting data. I've just updated it to work in the latest version of Chrome and Firefox

Upvotes: 1

Kyaw Tun
Kyaw Tun

Reputation: 13131

Actually IndexedDB will save your time as you move on. It is very easy to change version through versioning.

For tutorial, I really recommend my own http://dev.yathit.com/ydn-db/starting/query.html It is tutorial javascript indexeddb wrapper, but you can very quickly understand and feel of it. Read on chrome, safari and firefox, open dev console and copy and paste the code snippets, change a bit. Understanding important of key range is very important. There some trick around key genration and filtering cursor iterations.

I think it is because WebSQL query result is very different from JSON. With NoSQL, it is so stupid now why should we need define TABLE if we just want to persist a JSON object. IndexedDB is very very simple and very light weight as compare to WebSQL.

Upvotes: 0

Related Questions