Bug 106377 - IndexedDB: Allow createIndex/createObjectStore to be asynchronous
Summary: IndexedDB: Allow createIndex/createObjectStore to be asynchronous
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alec Flett
URL:
Keywords:
Depends on: 106117 106148
Blocks: 99774
  Show dependency treegraph
 
Reported: 2013-01-08 14:05 PST by Alec Flett
Modified: 2013-01-09 23:34 PST (History)
6 users (show)

See Also:


Attachments
Patch (87.09 KB, patch)
2013-01-08 15:25 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch (89.05 KB, patch)
2013-01-08 15:42 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch (85.86 KB, patch)
2013-01-09 17:21 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch (85.87 KB, patch)
2013-01-09 18:09 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch (85.88 KB, patch)
2013-01-09 18:12 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch for landing (88.19 KB, patch)
2013-01-09 21:55 PST, Alec Flett
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alec Flett 2013-01-08 14:05:21 PST
IndexedDB: Allow createIndex/createObjectStore to be asynchronous
Comment 1 Alec Flett 2013-01-08 15:25:48 PST
Created attachment 181784 [details]
Patch
Comment 2 Alec Flett 2013-01-08 15:39:46 PST
Comment on attachment 181784 [details]
Patch

oops, forgot one file
Comment 3 Alec Flett 2013-01-08 15:42:18 PST
Created attachment 181791 [details]
Patch
Comment 4 Alec Flett 2013-01-08 15:44:31 PST
jsbell@ / dgrogan@ - one more big review? Lots of code removal in this one :)
Comment 5 Joshua Bell 2013-01-08 17:21:21 PST
Comment on attachment 181791 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=181791&action=review

Overall LGTM...

> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:640
> +            return false;

This changes the semantics of this method from "plow ahead in case of error" to "fail the load completely". I don't disagree with this change, but it's orthogonal to the rest of the patch, isn't it? (Also, I'd rather that we just implemented the FIXME if we're going to change the behavior.)

> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:1017
> +            return false;

Ditto.

> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:1037
>      return indexes;

Should be return true ?

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.cpp:56
> +    const RefPtr<IDBBackingStore> m_backingStore;

Not for this patch (because it's consistent with other Operations), but given that we can get to the backing store via the transaction which is passed into perform(), we can probably eliminate this member from this and other Operations.

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.cpp:1347
> +    m_metadata.objectStores.clear();

Is this ever called with non-empty m_metadata.objectStores?

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.h:108
>      class VersionChangeOperation;

Remove this from IDBDatabaseBackendImpl class while the others are moving out too?

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.h:111
>      class VersionChangeAbortOperation;

Ditto?

> Source/WebCore/Modules/indexeddb/IDBObjectStoreBackendImpl.h:46
> +namespace IDBObjectStoreBackendImpl {

May want to add a FIXME indicating that this is temporary, and things in this namespace will move to ... ?

> Source/WebKit/chromium/tests/IDBDatabaseBackendTest.cpp:-50
> -TEST(IDBDatabaseBackendTest, BackingStoreRetention)

Any way to change this test rather than removing it? E.g. creating an IDBTransactionBackendImpl which holds a reference?
Comment 6 EFL EWS Bot 2013-01-08 17:25:13 PST
Comment on attachment 181791 [details]
Patch

Attachment 181791 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/15763293
Comment 7 WebKit Review Bot 2013-01-08 18:04:56 PST
Comment on attachment 181791 [details]
Patch

Attachment 181791 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/15764284
Comment 8 Alec Flett 2013-01-09 17:21:05 PST
Created attachment 182026 [details]
Patch
Comment 9 Alec Flett 2013-01-09 17:22:27 PST
showed the updated IDBDatabaseBackendTest to jsbell in person he sez "lgtm"

All other issues have been addressed.

tony@ - r?
Comment 10 WebKit Review Bot 2013-01-09 17:35:16 PST
Comment on attachment 182026 [details]
Patch

Attachment 182026 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/15761681
Comment 11 Peter Beverloo (cr-android ews) 2013-01-09 18:09:04 PST
Comment on attachment 182026 [details]
Patch

Attachment 182026 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/15762748
Comment 12 Alec Flett 2013-01-09 18:09:12 PST
Created attachment 182037 [details]
Patch
Comment 13 Alec Flett 2013-01-09 18:12:49 PST
Created attachment 182040 [details]
Patch
Comment 14 Tony Chang 2013-01-09 18:28:15 PST
Comment on attachment 182040 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=182040&action=review

> Source/WebCore/ChangeLog:35
> +        * Modules/indexeddb/IDBDatabaseBackendImpl.cpp: Add all create/delete operations.

Nit: I would say where these are copied from.

> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:608
> +// FIXME: This should do some error handling rather than plowing ahead when bad data is encountered.

Are there security implications of plowing ahead when bad data is encountered?

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.h:69
> +    virtual PassRefPtr<IDBObjectStoreBackendInterface> createObjectStore(int64_t id, const String& name, const IDBKeyPath&, bool autoIncrement, IDBTransactionBackendInterface*, ExceptionCode&)  { ASSERT_NOT_REACHED(); return 0; }
> +    virtual void createObjectStore(int64_t transactionId, int64_t objectStoreId, const String& name, const IDBKeyPath&, bool autoIncrement);
> +    virtual void deleteObjectStore(int64_t, IDBTransactionBackendInterface*, ExceptionCode&) { ASSERT_NOT_REACHED(); }
> +    virtual void deleteObjectStore(int64_t transactionId, int64_t objectStoreId);

Should these have OVERRIDE?
Comment 15 EFL EWS Bot 2013-01-09 19:48:14 PST
Comment on attachment 182040 [details]
Patch

Attachment 182040 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/15758795
Comment 16 Alec Flett 2013-01-09 21:55:49 PST
Created attachment 182061 [details]
Patch for landing
Comment 17 WebKit Review Bot 2013-01-09 23:07:37 PST
Comment on attachment 182061 [details]
Patch for landing

Rejecting attachment 182061 [details] from commit-queue.

New failing tests:
inspector-protocol/debugger-terminate-dedicated-worker-while-paused.html
Full output: http://queues.webkit.org/results/15774678
Comment 18 Alec Flett 2013-01-09 23:27:11 PST
Comment on attachment 182061 [details]
Patch for landing

sigh. Those are not my failures. trying again.
Comment 19 WebKit Review Bot 2013-01-09 23:34:38 PST
Comment on attachment 182061 [details]
Patch for landing

Clearing flags on attachment: 182061

Committed r139289: <http://trac.webkit.org/changeset/139289>
Comment 20 WebKit Review Bot 2013-01-09 23:34:43 PST
All reviewed patches have been landed.  Closing bug.