Does not pass all PouchDB tests

[brody4hire]

As reported by @nolanlawson in #247:

Hm, it gets to 49% and then just stops (Android 4.4 emulator + SQLite
plugin). In logcat I see a lot of:

GC_FOR_ALLOC freed 1230K, 18% free 6185K/7492K, paused 2ms, total 2ms

But that's only while it's working.

Once it stops working, the last failed test is Test _conflicts key in the
replication tests. Also I see in the logs a lot of:

  1821         eglCodecCommon  E  **** ERROR unknown type 0x0 (glSizeof,72)
  1821         eglCodecCommon  E  glUtilsParamSize: unknow param 0x00000b44
  1821         eglCodecCommon  E  glUtilsParamSize: unknow param 0x00000bd0

^ This is repeated over and over again.

and another comment by @nolanlawson:

I'm guessing this is some kind of memory leak, because once I restart the tests it works fine again... for awhile.

NOTEs:

• We did not (so far) try this with the Crosswalk version on Cordova on Android.
• @nolanlawson we should try this with androidDatabaseImplementation option set to 2 in sqlitePlugin.openDatabase() (as specified in README.md) and check results (also did we check this for iOS?)
• Blob support is removed (from Android and iOS versions) and I would like to treat blobs with lower priority until we get some more urgent issues sorted

[nolanlawson]

Anybody who wants to help out on this: it is exceedingly easy to run the PouchDB test suite on your own machine, as described here.

[brody4hire]

Quoted for reference here:

It's literally as easy as:

git clone https://github.com/pouchdb/pouchdb.git
cd pouchdb
npm install
# start up an Android emulator
SQLITE_PLUGIN=true ADAPTERS=websql npm run cordova

EDIT: you also have to start the CouchDB server on your localhost, as described at: https://github.com/pouchdb/pouchdb/blob/master/TESTING.md

Then it will run the test in your emulator like so:

[brody4hire]

@nolanlawson I think it goes without saying that this should have been my task. Will take a look early next week.

[brody4hire]

And for #236/#259: I am extremely grateful that J.F. Spencer is willing to help us with testing, measuring, and improving the performance. Let contributors in the community work where the like best :)

[nolanlawson]

@brodybits No prob; I was going to look into it this weekend as well. :) BTW I updated the code snippet above; you no longer need a special branch, because pouchdb master is now cordova-friendly.

[nolanlawson]

FWIW, I just manually confirmed 100% tests passing for Cordova apps in:

• Android 5.1, 4.4, and 4.2
• iOS 8.3
• Firefox OS 3.0.0

I found the fastest way with Android is to use Genymotion, then (assuming CouchDB is installed) using the option:

COUCH_HOST=http://10.0.3.2:5984 npm run cordova

(This was just a sanity check to make sure that the problem wasn't with PouchDB itself.)

[brody4hire]

FWIW, I just manually confirmed 100% tests passing for Cordova apps in:

• Android 5.1, 4.4, and 4.2
• iOS 8.3
• Firefox OS 3.0.0

Do you mean that you tested with my plugin, or something else?

Also how are you running the tests with Firefox OS, which this plugin does not (yet) support?

[nolanlawson]

Ah sorry for the confusion, I meant I was testing without the plugin. :) Just a sanity check to make sure that the failures were really due to this plugin.

And yeah, I don't blame ya for not supporting FirefoxOS, given that they didn't make it possible. ;)

[brody4hire]

I remember something now, which I discovered from BUG #232. If tx.executeSql() calls the error handler: the plugin will continue only if the error handler returns false, while Web SQL continues if the error handler returns a non-true handler. (I tested what if the error handler returns 1 or a non-empty string, and both the plugin and websql will abort the transaction in this case.) This was due to a change that I accepted from PR #170 (and missing test coverage as well).

[brody4hire]

Of course, the problem in #232 would be very easy to fix, but I try to follow a test-first approach (which may not always be the best thing). The workaround (as I said in #232) is for the SQL error handler to explicitly return false if the transaction should be recovered.

Also, #226 uncovered another issue. If a transaction SQL error handler returns TRUE, no more SQL callbacks should be fired before aborting the transaction.

Today is my sabbath and I am taking off now, I am happy to work on this tonight. What I am thinking is to first try to get the full test suite working in Travis/Circle CI, then fix #232 and perhaps #226.