ServiceWorker: Manipulate uncommitted/purgeable resource ids

content/browser/service_worker/service_worker_database.h

Index: content/browser/service_worker/service_worker_database.h
diff --git a/content/browser/service_worker/service_worker_database.h b/content/browser/service_worker/service_worker_database.h
index f27cc2462b1e91f61fbcc5681011a282b7aaa2bd..3f9eb96be366224d43d5b88097397aa8c8ff8608 100644
--- a/content/browser/service_worker/service_worker_database.h
+++ b/content/browser/service_worker/service_worker_database.h
@@ -96,6 +96,37 @@ class CONTENT_EXPORT ServiceWorkerDatabase {
   bool DeleteRegistration(int64 registration_id,
                           const GURL& origin);
 
+  // As new resources are put into the diskcache, they go into an uncommitted
+  // list. When a registration is saved that refers to those ids, they're
+  // removed from that list. When a resource no longer has any registrations or
+  // caches referring to it, it's added to the unclaimed list. Periodically,

[michaeln, 2014/04/29 23:50:03]

the language in the comment is a little stale, 'unclaimed' s/b 'purgeable'

[nhiroki, 2014/04/30 03:05:58]

Done.

+  // the unclaimed list can be purged from the diskcache. At system startup, all
+  // uncommitted ids are moved to the purgeable list.
+
+  // Reads uncommitted resource ids from the database. Returns true on success.
+  // Otherwise clears |ids| and returns false.
+  bool GetUncommittedResourceIds(std::set<int64>* ids);

[michaeln, 2014/04/29 23:50:03]

As a consumer of this api, i was thinking a std::vector<> would be good here
(and in the others). Is there a reason to use std::set<> instead?

[nhiroki, 2014/04/30 03:05:58]

This is just implementation issue. LevelDB seems not to be able to deduplicate
keys from a write batch, so if a vector contains duplicated keys, a batch issues
multiple operations for them.

If consumers prefer to use the vector version, I'll inline code for
deduplication into these functions. Wdyt?

[michaeln, 2014/04/30 03:23:57]

Which result in the last one value added to the batch for that key being stored,
is that right?

Ok, thnx for explaining the set<> usage.

[nhiroki, 2014/04/30 04:04:06]

Yes, records having the same key are operated in FIFO order and the last one
will survive.

+
+  // Writes |ids| into the database as uncommitted resources. Returns true on
+  // success. Otherwise writes nothing and returns false.
+  bool WriteUncommittedResourceIds(const std::set<int64>& ids);
+
+  // Deletes uncommitted resource ids specified by |ids| from the database.
+  // Returns true on success. Otherwise deletes nothing and returns false.
+  bool ClearUncommittedResourceIds(const std::set<int64>& ids);
+
+  // Reads purgeable resource ids from the database. Returns true on success.
+  // Otherwise clears |ids| and returns false.
+  bool GetPurgeableResourceIds(std::set<int64>* ids);
+
+  // Writes |ids| into the database as purgeable resources. Returns true on
+  // success. Otherwise writes nothing and returns false.
+  bool WritePurgeableResourceIds(const std::set<int64>& ids);
+
+  // Deletes purgeable resource ids specified by |ids| from the database.
+  // Returns true on success. Otherwise deletes nothing and returns false.
+  bool ClearPurgeableResourceIds(const std::set<int64>& ids);
+
   bool is_disabled() const { return is_disabled_; }
   bool was_corruption_detected() const { return was_corruption_detected_; }