[webkit-reviews] review requested: [Bug 40627] Limit ApplicationCache Total and Per-Origin Storage Capacity (Quotas) : [Attachment 59545] [PATCH] Part 2 - Update Schema and enforce Per-Origin Quotas (needs part 1)

[bugzilla-daemon at webkit.org]

Joseph Pecoraro <joepeck at webkit.org> has asked	for review:
Bug 40627: Limit ApplicationCache Total and Per-Origin Storage Capacity
(Quotas)
https://bugs.webkit.org/show_bug.cgi?id=40627

Attachment 59545: [PATCH] Part 2 - Update Schema and enforce Per-Origin Quotas
(needs part 1)
https://bugs.webkit.org/attachment.cgi?id=59545&action=review

------- Additional Comments from Joseph Pecoraro <joepeck at webkit.org>
ChangeLog says it all. I made a decision here that could be debated:

In the Patch:
I ensure that `Origins` records only exist when there is a `Caches`
record that needs it. So, the lifetime of the quota is tied to whether
or not the origin has an application cache. If all caches on that
origin get deleted then the quota will be deleted as well.
  + There are never extra Origins records.
  - Requires an extra SELECT to count the number of Origin Records

Alternate Solution:
`Origins` records, and therefore quotas, should remain permanently,
or until the database is explicitly emptied. This way, once they are set
by the user for an origin, if the cache is deleted and later restored the
originally set quota would still be in effect.
  + Prevent reaching a low quota multiple times if caches come and go
  - May leave around stale Origins records.

Finally, I started taking the Databases Quota management approach, but
felt that was far to heavyweight. The approach I took just grabs the quota
and checks it again before committing to the new cache. The second
check may need to move into a SQL Transaction for storeNewestCache.