[Webkit-unassigned] [Bug 51110] IDBCursor::delete is not implemented.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 17 07:29:32 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=51110





--- Comment #4 from Andrei Popescu <andreip at google.com>  2010-12-17 07:29:33 PST ---
(In reply to comment #2)
> (From update of attachment 76651 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=76651&action=review
> 
> Overall, looks great.
> 
> > LayoutTests/storage/indexeddb/cursor-delete.html:1
> > +<html>
> 
> Whats this?
> 

No idea, Visual Studio generated that :(

> > LayoutTests/storage/indexeddb/cursor-delete.html:48
> > +    commitAndContinue();
> 
> Don't do this.  I've been removing it as fast as I can, but apparnetly it's not fast enough.  This is not a valid way of doing this.  Set oncomplete
> 

Fixed.


> > LayoutTests/storage/indexeddb/cursor-delete.html:163
> > +    deleteResult.onsuccess = iterateCursor;
> 
> You could even just call continue here since it's supposed to run after the delete happens.
>

Removed this since we have a pre-existing bug here. Will file a separate bug for the situation where we delete an item using objectStore.delete() while we're in the middle of iterating a cursor over the same objectStore.

> > WebCore/storage/IDBCursorBackendImpl.cpp:170
> > +    // if (m_transaction->mode() == IDBTransaction::READ_ONLY) {
> 
> We should be able to re-enable now.
> 

Doesn't work, I tried. Perhaps another bug?

> > WebCore/storage/IDBIndexBackendImpl.cpp:107
> > +    RefPtr<IDBCursorBackendInterface> cursor = IDBCursorBackendImpl::create(index->m_database.get(), range, direction, query.release(), objectCursor, transaction.get(), 0);
> 
> You don't test this case.  And if you did, you'd see a crash I'm pretty sure.  I'm not sure how we can supply this without making cycles though.  :-/

Oops, fixed. Note that when we were deleting from an object store, we weren't deleting the data from the associated index. Fixed that too.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list