RESOLVED FIXED 88829
IndexedDB: Add tests, an assert, and some comments around open/close/setVersion call sequencing
https://bugs.webkit.org/show_bug.cgi?id=88829
Summary IndexedDB: Add tests, an assert, and some comments around open/close/setVersi...
David Grogan
Reported 2012-06-11 18:39:41 PDT
IndexedDB: Add tests, an assert, and some comments
Attachments
Patch (13.75 KB, patch)
2012-06-11 18:41 PDT, David Grogan
no flags
Patch (14.41 KB, patch)
2012-06-12 16:39 PDT, David Grogan
no flags
Patch (14.36 KB, patch)
2012-06-12 16:47 PDT, David Grogan
no flags
Patch (14.46 KB, patch)
2012-06-12 17:28 PDT, David Grogan
no flags
Patch for landing (14.47 KB, patch)
2012-06-13 09:57 PDT, David Grogan
no flags
David Grogan
Comment 1 2012-06-11 18:41:20 PDT
David Grogan
Comment 2 2012-06-11 18:45:59 PDT
Some tests and comments I added while looking through our pending call queues.
Joshua Bell
Comment 3 2012-06-12 14:54:32 PDT
Comment on attachment 146989 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=146989&action=review > Source/WebCore/ChangeLog:3 > + IndexedDB: Add tests, an assert, and some comments Be more specific about the domain of the changes, e.g. "around open/close/setVersion call sequencing" > Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.cpp:291 > + // If there were any pending set version calls, we better have started one. Only true if there is only one connection to this database, correct? If that's the case, can we ASSERT on that at the start of the function? (That's a surprise to me - I thought we called processPendingCalls() more often. Either way, we should be assertive about it.) > Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.cpp:317 > + // Given the check above, it appears that calls cannot be requeued by Add an ASSERT at the end of the function that m_pendingOpenCalls is empty? > LayoutTests/storage/indexeddb/factory-deletedatabase-interactions-expected.txt:74 > +PASS self.steps.toString() is "h.open,h.open.onsuccess,h2.open,h2.open.onsuccess,h.setVersion,deleteDatabase(),h2.onversionchange,h.setVersion.onblocked,h3.open,h2.close,h.setVersion.onsuccess,h.setVersion.transaction-complete,h.onversionchange,deleteDatabase().onblocked,h.close,deleteDatabase().onsuccess,h3.open.onsuccess" Feel free to rewrite this test if it'll improve comprehensibility. (It seemed like a good idea at the time, but looks a little "too clever" to me now.)
David Grogan
Comment 4 2012-06-12 16:39:17 PDT
Comment on attachment 146989 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=146989&action=review Added a few ASSERTS. Those invariants might change shortly, but awareness of what changes is the point here. >> Source/WebCore/ChangeLog:3 >> + IndexedDB: Add tests, an assert, and some comments > > Be more specific about the domain of the changes, e.g. "around open/close/setVersion call sequencing" Done. >> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.cpp:291 >> + // If there were any pending set version calls, we better have started one. > > Only true if there is only one connection to this database, correct? If that's the case, can we ASSERT on that at the start of the function? > > (That's a surprise to me - I thought we called processPendingCalls() more often. Either way, we should be assertive about it.) We call processPendingCalls when the last or second to last connection has closed and when a version change transaction has finished. So yeah, we only call it when there is at most one remaining connection, good catch. ASSERT added. >> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.cpp:317 >> + // Given the check above, it appears that calls cannot be requeued by > > Add an ASSERT at the end of the function that m_pendingOpenCalls is empty? Done.
David Grogan
Comment 5 2012-06-12 16:39:55 PDT
David Grogan
Comment 6 2012-06-12 16:47:34 PDT
Joshua Bell
Comment 7 2012-06-12 16:51:12 PDT
Comment on attachment 147192 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147192&action=review > LayoutTests/storage/indexeddb/resources/factory-deletedatabase-interactions.js:20 > + debug(" in versionchange, old = " + e.target.version + " new = " + e.version); Really minor, but maybe use JSON.stringify(e.target.version) and JSON.stringify(e.version) so they're quoted when strings? (The output currently looks a bit odd when there's no old version.)
David Grogan
Comment 8 2012-06-12 16:54:00 PDT
Comment on attachment 147192 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147192&action=review >> LayoutTests/storage/indexeddb/resources/factory-deletedatabase-interactions.js:20 >> + debug(" in versionchange, old = " + e.target.version + " new = " + e.version); > > Really minor, but maybe use JSON.stringify(e.target.version) and JSON.stringify(e.version) so they're quoted when strings? (The output currently looks a bit odd when there's no old version.) SG.
David Grogan
Comment 9 2012-06-12 17:28:12 PDT
David Grogan
Comment 10 2012-06-12 18:42:17 PDT
Tony, could you review this?
Tony Chang
Comment 11 2012-06-13 09:44:13 PDT
Comment on attachment 147200 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147200&action=review > LayoutTests/storage/indexeddb/resources/three-setversion-calls.js:48 > + if (i == 0) { Nit: if (!i) would be WebKit style.
David Grogan
Comment 12 2012-06-13 09:52:52 PDT
Comment on attachment 147200 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147200&action=review >> LayoutTests/storage/indexeddb/resources/three-setversion-calls.js:48 >> + if (i == 0) { > > Nit: if (!i) would be WebKit style. Thanks, fixed.
David Grogan
Comment 13 2012-06-13 09:57:42 PDT
Created attachment 147348 [details] Patch for landing
WebKit Review Bot
Comment 14 2012-06-13 10:31:09 PDT
Comment on attachment 147348 [details] Patch for landing Clearing flags on attachment: 147348 Committed r120222: <http://trac.webkit.org/changeset/120222>
WebKit Review Bot
Comment 15 2012-06-13 10:31:20 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.