Implementation of OnDiskAttachmentStore.

sync/internal_api/public/attachments/on_disk_attachment_store.h

Index: sync/internal_api/public/attachments/on_disk_attachment_store.h
diff --git a/sync/internal_api/public/attachments/on_disk_attachment_store.h b/sync/internal_api/public/attachments/on_disk_attachment_store.h
new file mode 100644
index 0000000000000000000000000000000000000000..3f98275301615b08c25c40dce3c3d2bde84be322
--- /dev/null
+++ b/sync/internal_api/public/attachments/on_disk_attachment_store.h
@@ -0,0 +1,58 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef SYNC_INTERNAL_API_PUBLIC_ATTACHMENTS_ON_DISK_ATTACHMENT_STORE_H_
+#define SYNC_INTERNAL_API_PUBLIC_ATTACHMENTS_ON_DISK_ATTACHMENT_STORE_H_
+
+#include "base/files/file_path.h"
+#include "base/memory/ref_counted.h"
+#include "base/single_thread_task_runner.h"
+#include "base/threading/non_thread_safe.h"
+#include "sync/api/attachments/attachment.h"
+#include "sync/api/attachments/attachment_id.h"
+#include "sync/api/attachments/attachment_store.h"
+#include "sync/base/sync_export.h"
+
+namespace leveldb {
+class DB;
+}  // namespace leveldb
+
+namespace syncer {
+
+// On-disk implementation of AttachmentStore. Stores attachments in leveldb
+// database in |path| directory.
+class SYNC_EXPORT OnDiskAttachmentStore : public AttachmentStoreBase,
+                                          public base::NonThreadSafe {
+ public:
+  // Constructs attachment store. |path| is directory where files will be
+  // created.

[maniscalco, 2014/10/14 21:03:19]

What happens if the path does not exist?

What happens if a database already exists at the path?

[pavely, 2014/10/16 22:13:30]

Done.

+  OnDiskAttachmentStore(
+      const base::FilePath& path,
+      const scoped_refptr<base::SingleThreadTaskRunner>& callback_task_runner);
+  virtual ~OnDiskAttachmentStore();
+
+  // AttachmentStoreBase implementation.
+  // Load opens database, creating it if needed. In the future upgrade code will
+  // be invoked from Load as well. If loading fails it posts |callback| with
+  // UNSPECIFIED_ERROR.
+  virtual void Load(const LoadCallback& callback) override;

[maniscalco, 2014/10/15 16:16:36]

As we talked about in person...

- it would be nice if AttachmentStores were "protocol-less".  That is, if you
have an instance of one, you don't have to worry about it being properly
initialized or not because whatever created it took care of that already.

- we can make the static factory functions that create+initialize
AttachmentStores asynchronous (i.e. they will take a callback parameter that
"returns" the newly created and initialized AttachmentStore).

[pavely, 2014/10/16 22:13:30]

Done.

+  virtual void Read(const AttachmentIdList& ids,
+                    const ReadCallback& callback) override;
+  virtual void Write(const AttachmentList& attachments,
+                     const WriteCallback& callback) override;
+  virtual void Drop(const AttachmentIdList& ids,
+                    const DropCallback& callback) override;
+
+ private:
+  void FormatAttachmentDataKey(const AttachmentId& attachment_id,

[maniscalco, 2014/10/14 21:03:19]

Would CreateKeyFromAttachmentId be a better name?  When I see a FormatFoo method
on a database-like class, I wonder if it's similar to formatting a disk.

[pavely, 2014/10/16 22:13:30]

Done.

+                               std::string* key);
+
+  base::FilePath path_;
+  scoped_refptr<base::SingleThreadTaskRunner> callback_task_runner_;
+  scoped_ptr<leveldb::DB> db_;
+};
+
+}  // namespace syncer
+
+#endif  // SYNC_INTERNAL_API_PUBLIC_ATTACHMENTS_ON_DISK_ATTACHMENT_STORE_H_