WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
103964
IndexedDB: Abort transactions because of leveldb errors part 4
https://bugs.webkit.org/show_bug.cgi?id=103964
Summary
IndexedDB: Abort transactions because of leveldb errors part 4
David Grogan
Reported
2012-12-03 20:02:22 PST
IndexedDB: Abort transactions because of leveldb errors part 4
Attachments
Patch
(10.26 KB, patch)
2012-12-03 20:05 PST
,
David Grogan
no flags
Details
Formatted Diff
Diff
Patch
(13.52 KB, patch)
2012-12-04 16:04 PST
,
David Grogan
no flags
Details
Formatted Diff
Diff
Patch
(14.18 KB, patch)
2012-12-04 19:05 PST
,
David Grogan
no flags
Details
Formatted Diff
Diff
Patch
(14.24 KB, patch)
2012-12-04 19:28 PST
,
David Grogan
no flags
Details
Formatted Diff
Diff
Patch
(13.96 KB, patch)
2012-12-05 16:39 PST
,
David Grogan
no flags
Details
Formatted Diff
Diff
Patch
(14.08 KB, patch)
2012-12-05 17:03 PST
,
David Grogan
no flags
Details
Formatted Diff
Diff
Patch
(14.41 KB, patch)
2012-12-06 12:06 PST
,
David Grogan
no flags
Details
Formatted Diff
Diff
Show Obsolete
(6)
View All
Add attachment
proposed patch, testcase, etc.
David Grogan
Comment 1
2012-12-03 20:05:05 PST
Created
attachment 177399
[details]
Patch
David Grogan
Comment 2
2012-12-04 16:04:04 PST
Created
attachment 177593
[details]
Patch
David Grogan
Comment 3
2012-12-04 19:05:57 PST
Created
attachment 177648
[details]
Patch
David Grogan
Comment 4
2012-12-04 19:28:28 PST
Created
attachment 177652
[details]
Patch
David Grogan
Comment 5
2012-12-05 16:39:55 PST
Created
attachment 177863
[details]
Patch
David Grogan
Comment 6
2012-12-05 17:03:16 PST
Created
attachment 177871
[details]
Patch
David Grogan
Comment 7
2012-12-05 17:04:03 PST
Josh or Alec, could one of you take a look?
Joshua Bell
Comment 8
2012-12-05 17:48:55 PST
Comment on
attachment 177871
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=177871&action=review
Overall lgtm...
> Source/WebKit/chromium/ChangeLog:-360 > -2012-11-30 David Grogan <
dgrogan@chromium.org
>
Automatic merge glitch?
> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:125 > +WARN_UNUSED_RETURN static bool getVarInt(DBOrTransaction* db, const LevelDBSlice& key, int64_t& foundInt, bool& found)
Just curious - is this placement required for implementations? In forward/class declarations I've seen it after the (), although it looks like you used it as a prefix in IDBObjectStoreBackendImpl.cpp.
> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:373 > + found = getInt(m_db.get(), key, metadata->id);
getInt() will get the found-vs.-error treatment in a later patch?
> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:382 > + ASSERT(found);
Would !found would indicate a coding consistency error, correct? That is, LevelDB didn't report an error but the metadata was malformed? Should that be an InternalError as well, just a different type?
> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:389 > + ASSERT(found);
Ditto. (This could e.g. indicate a problem with the schema migration code.)
> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:641 > + bool ok = getString(levelDBTransaction, ObjectStoreMetaDataKey::encode(databaseId, objectStoreId, ObjectStoreMetaDataKey::Name), objectStoreName, found);
Add an ASSERT(found) and/or InternalError if !found?
Joshua Bell
Comment 9
2012-12-05 17:50:42 PST
Comment on
attachment 177871
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=177871&action=review
> Source/WebCore/Modules/indexeddb/IDBBackingStore.h:55 > + virtual bool getIDBDatabaseMetaData(const String& name, IDBDatabaseMetadata*, bool& success) WARN_UNUSED_RETURN;
Oops, also meant to say: Probably too late now, but I wonder if "typedef bool BackingStoreSuccess;" would improve readability for these headers.
David Grogan
Comment 10
2012-12-05 19:14:43 PST
Comment on
attachment 177871
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=177871&action=review
>> Source/WebKit/chromium/ChangeLog:-360 >> -2012-11-30 David Grogan <
dgrogan@chromium.org
> > > Automatic merge glitch?
There was the other day, I'm retroactively correcting it here. *shrug*
>> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:125 >> +WARN_UNUSED_RETURN static bool getVarInt(DBOrTransaction* db, const LevelDBSlice& key, int64_t& foundInt, bool& found) > > Just curious - is this placement required for implementations? In forward/class declarations I've seen it after the (), although it looks like you used it as a prefix in IDBObjectStoreBackendImpl.cpp.
In class method declarations it definitely goes after the (). In non-static standalone functions it also goes after the (). For some reason in static functions it goes in the beginning. Take this with a grain of salt though, it was obtained through trial and error.
>> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:373 >> + found = getInt(m_db.get(), key, metadata->id); > > getInt() will get the found-vs.-error treatment in a later patch?
Yep. It's the last place that drops errors that I know of. Once its callers are updated, this work is done.
>> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:382 >> + ASSERT(found); > > Would !found would indicate a coding consistency error, correct? That is, LevelDB didn't report an error but the metadata was malformed? Should that be an InternalError as well, just a different type?
For getString, I think it can only mean that the key wasn't found. For getVarInt you're right, it could indicate an encoding error as well. I had wanted the return value to indicate that leveldb reported an error, so !found shouldn't cause a |return false|. But after thinking about it, a different InternalError along with a return false would probably be best. We don't want release mode to proceed in the (ok && !found) case, we want an abort.
>> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:389 >> + ASSERT(found); > > Ditto. (This could e.g. indicate a problem with the schema migration code.)
Good point. Yeah, will change back.
>> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:641 >> + bool ok = getString(levelDBTransaction, ObjectStoreMetaDataKey::encode(databaseId, objectStoreId, ObjectStoreMetaDataKey::Name), objectStoreName, found); > > Add an ASSERT(found) and/or InternalError if !found?
Oops. Will add.
>> Source/WebCore/Modules/indexeddb/IDBBackingStore.h:55 >> + virtual bool getIDBDatabaseMetaData(const String& name, IDBDatabaseMetadata*, bool& success) WARN_UNUSED_RETURN; > > Oops, also meant to say: > > Probably too late now, but I wonder if "typedef bool BackingStoreSuccess;" would improve readability for these headers.
I like that idea. Seems like a patch that could be easily slipped whenever (so, not too late).
David Grogan
Comment 11
2012-12-06 12:06:54 PST
Created
attachment 178055
[details]
Patch
David Grogan
Comment 12
2012-12-06 12:08:09 PST
Now with more aborting per Josh's suggestions.
David Grogan
Comment 13
2012-12-06 14:34:08 PST
Tony, could you review this?
WebKit Review Bot
Comment 14
2012-12-06 14:57:22 PST
Comment on
attachment 178055
[details]
Patch Clearing flags on attachment: 178055 Committed
r136897
: <
http://trac.webkit.org/changeset/136897
>
WebKit Review Bot
Comment 15
2012-12-06 14:57:26 PST
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.
Top of Page
Format For Printing
XML
Clone This Bug