pouchdb: [bug] WebSQL adapter not detected correctly in pouchdb-adapter-websql/src/valid.js (when SQLite Plugin 2 + Cordova used)

Environment

Hybrid App

  • cordova 6.2.0
  • cordova-plugin-wkwebview-engine
  • cordova-labs-local-webserver
  • cordova-plugin-sqlite-2

Browser/platform

iOS 9.3.2 WKWebView via cordova plugin

Adapter

WebSQL - via cordova-plugin-sqlite-2

Server CouchDB

CouchDB

Please describe your issue.

I have a hybrid app running successfully on iOS 9.3.2 using the faster WKWebView and PouchDB 5.3.2 ( {adapter: 'websql'} and cordova-plugin-sqlite-2. All good.

If I change nothing else but bump my package.json pouchdb version to 5.4.x and then npm install and build/run my app on my device I get the error: Error: Adapter is missing

I had to dig for the error using Safari Dev tools and found it in the taskqueue of my local db object. i.e.

var db = new PouchDB('mydb', {adapter: 'websql', revs_limit: 100, auto_compaction: true});
console.log(db);    // db.taskqueue.failed : 'Error: Adapter is missing'

If I swap back to 5.3.2, all is good and app works perfectly.

I noticed there were some deprecations in 5.4.0 but not sure if these are to blame. I’m more suspicious of bugfix #5197 / PR #5198. I get why this fix was introduced for browser validation, but with cordova + sqlite plugin 2 we can get it to work. Are we artificially disabling websql here for cordova apps too ?

Edit: Turns out we are: valid.js#L56 assumes a SQLitePlugin object is defined before deviceready.

But with cordova-plugin-sqlite-2 the object isn’t available until the deviceready event fires and it is different casing sqlitePlugin i.e. there is no SQLitePlugin object ever.

I fixed my problem by adding return true; at the beginning of function valid() so it is definitely an artificial PouchDB imposed limitation for Cordova users. Now I can run PouchDB 5.4.4 (with the above mod to valid.js) on iOS 9.3.2 using the faster WKWebView + cordova-plugin-sqlite-2. Boom.

This may fix @tropperstyle 's issue in #5386 too.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 31 (25 by maintainers)

Commits related to this issue

Most upvoted comments

@dharders I have more update on this issue. I confirm the flaky success are linked to a window.cordova not being defined. That’s depending on the order of the loading of my assets. My workaround seems the best solution available.

Regarding the performances of using async. I had forgotten to put the main script async too. That was blocking the rendering. After deferring this script and the CSS, the first paint is around 200ms instead of 1.5s. That’s much better 🚀 . (However, notice that the interaction ready time is pretty much the same 😞 )

I should clarify to say no real ‘noticeable’ penalty. ( in my testing anyway). I was more interested in whether the modification fixed your issue.

It’s a requirement to have cordova instantiated before pouchdb to work with wkwebview/sqlite 2 so I don’t think you’re gonna get around it, unless you can somehow guarantee the order with lazy loading (which I’m unaware of due to the async nature)

If this fixed your issue, please start a new ‘performance’ issue (probably in Cordova repo) so we don’t get off topic here. But if your issue still remains, please keep the conversation going so we can fix it for everyone.

Without actually testing against the platforms the mocks will just confirm that the code is doing what we wrote, without getting cordova in CI manually verifying is about the best we can do, hopefully idb-next sorts all this out 😃 fixed in https://github.com/pouchdb/pouchdb/commit/f05ec7cc265a67c27fd89baa5d5e00c8a1e9a95c

Oh lol, I didn’t even notice the SQLitePlugin vs sqlitePlugin difference. Dumb typo on my part.

I’d be in favor of just adding typeof cordova !== 'undefined' to the valid() function. If a user is on Cordova, they can always install the SQLite Plugin.