Bug 104592 – IndexedDB: Stub out data operations on IDBDatabaseBackendInterface

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Alec Flett]

IndexedDB: Stub out data operations on IDBDatabaseBackendInterface

[Alec Flett]

Created attachment 178625 [details]
Patch

[Alec Flett]

jsbell@ / dgrogan@ - mind a quick look? just stubs.

[Alec Flett]

Comment on attachment 178625 [details]
Patch

jsbell@ / dgrogan@ - oops false alarm, I forgot put()! Ignore this patch

[Alec Flett]

Created attachment 178632 [details]
Patch

[Alec Flett]

jsbell@ / dgrogan@ - ok, this is ready now. quick review?

[Joshua Bell]

Comment on attachment 178632 [details]
Patch

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

Seems fine to me with nits and questions...

> Source/WebCore/ChangeLog:12
> +        No new tests, this is just preparation for refactoring.

Does this unblock work on the Chromium side, or is this really just the outline?

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.cpp:351
> +void IDBDatabaseBackendImpl::openKeyCursor(int64_t transactionId, int64_t objectStoreId, int64_t indexId, PassRefPtr<IDBKeyRange>, unsigned short direction, PassRefPtr<IDBCallbacks>)

Start off with these methods ordered (alphabetically or logically)

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendImpl.h:83
> +    virtual void openKeyCursor(int64_t transactionId, int64_t objectStoreId, int64_t indexId, PassRefPtr<IDBKeyRange>, unsigned short direction, PassRefPtr<IDBCallbacks>);

openKeyCursor is missing from IDBDatabaseBackendInterface

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendInterface.h:69
> +    enum PutMode {

I would change references to IDBObjectStoreBackendInterface::AddOnly at the same time as you add this (no reason existing uses can't point at this).

Also consider moving IDBCursor::Direction here too? Or deferring Cursor refactoring for later?

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendInterface.h:77
> +    virtual void openCursor(int64_t transactionId, int64_t objectStoreId, int64_t indexId, PassRefPtr<IDBKeyRange>, unsigned short direction, bool keyOnly, PassRefPtr<IDBCallbacks>) = 0;

Would this be a good time to move IDBKeyRange from being refcounted to stack allocated?

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendInterface.h:79
> +    virtual void get(int64_t transactionId, int64_t objectStoreId, int64_t indexId, PassRefPtr<IDBKeyRange>, PassRefPtr<IDBCallbacks>) = 0;

Presumably passing some special id for indexId means "get from the object store" ?

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendInterface.h:82
> +    virtual void setIndexKeys(int64_t transactionId, int64_t objectStoreId, PassRefPtr<IDBKey> prpPrimaryKey, const Vector<int64_t>& indexIds, const Vector<IndexKeys>&) = 0;

Ditto for IDBKey? That would leave IDBCallbacks as the only refcounted type in this interface.

> Source/WebCore/Modules/indexeddb/IDBDatabaseBackendInterface.h:84
> +    virtual void deleteRange(int64_t transactionId, int64_t objectStoreId, PassRefPtr<IDBKeyRange>, PassRefPtr<IDBCallbacks>) = 0;

On further reflection (from offline conversation), I think I'd prefer keeping clear() here.

[Alec Flett]

Created attachment 178851 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[Alec Flett]

ok, everything is fully flushed out now, most comments addressed. I didn't go with the stack-allocatable IDBKeyRange / IDBKey for this round, I think the changes are going to be big/complicated enough as they are.

[WebKit Review Bot]

Comment on attachment 178851 [details]
Patch

Clearing flags on attachment: 178851

Committed r137381: <http://trac.webkit.org/changeset/137381>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Joshua Bell]

*** Bug 102742 has been marked as a duplicate of this bug. ***