[Webkit-unassigned] [Bug 107772] Adds usage instrumentation for indexedDB

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from Joshua Bell <jsbell at chromium.org>  2013-01-25 08:04:26 PST ---
(From update of attachment 184583)
View in context: https://bugs.webkit.org/attachment.cgi?id=184583&action=review

>> Source/WebCore/Modules/indexeddb/IDBBackingStore.cpp:356
>> +    IDBCreateObjectStore,
> 
> FYI, the enum at the top of this file, IDBBackingStoreErrorSource, essentially lists methods in this file and might be a better place for these new entries. Or you might want a new enum that is just for API methods. Whatever jsbell@ is ok with is fine.

David's right, I wasn't looking at the whole file.

The existing histograms/enums are used for (1) identifying the source of errors, and (2) flow through open() which has complex branching logic and ideally where on-disk corruption shows up.

This new histogram is just tracking API usage, but at the backing store level. That leads to a question: why track here, rather than at the entry point from script (e.g. for create/put/etc calls) and event delivery (e.g. transaction creation/complete/abort)? There are pros and cons to each approach (e.g. simpler to do it at the backing store level and maps to actual data changes, v.s. correlating exact with script calls). Without knowing what you're attempting to learn from this (i.e. what actions would we take based on this data? is it for helping users debug their script in local Chrome sessions?) it's hard to know which to recommend.

Either way, given how specific the other two enums are I'd actually recommend separating this out into a third enum, and leaving the existing ones alone (and focused on errors). It will probably make the code clearer and analysis of the histogram data easier.

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