[SyncFS] Implement methods to handle TrackerIDSet by FileID

[SyncFS] Implement methods to handle TrackerIDSet by FileID
Most methods simulate TrackerIDSet structure on LevelDB entries.
GetTrackerIDSetByPrefix() builds up a real TrackerIDSet to
get gathered information.



BUG=347425
TEST=./unit_tests --gtest_filter="MetadataDatabaseIndexOnDiskTest*"

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=282305

[peria, 2014-07-09 04:55:30]

PTL.

[tzik, 2014-07-09 06:39:46]

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
File
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc
(right):

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc:89:
oss << kTrackerIDByFileIDKeyPrefix << file_id << '\x00';
s/'\x00'/'\0'/?
Doesn't [prefix + file_id + '\0'] work?

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc:501:
const std::string prefix(
could you use "=" for the initialization, here and elsewhere?
I think it a bit more readable.

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc:549:
const std::string& prefix(
could you use value instead of cref to hold the return value, here and
elsewhere?
cref doesn't have performance advantage for this usage, and somewhat fragile.

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc:571:
// Deletions are not run yet, so the number looks +1 larger than real.
"Deletions have not ran" or "Deletion is not completed"?

[peria, 2014-07-09 07:34:50]

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
File
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc
(right):

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc:89:
oss << kTrackerIDByFileIDKeyPrefix << file_id << '\x00';
On 2014/07/09 06:39:46, tzik wrote:
> s/'\x00'/'\0'/?
> Doesn't [prefix + file_id + '\0'] work?

Done.
It works.  Used '\x00' just for the consistency with the Schema comment.

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc:501:
const std::string prefix(
On 2014/07/09 06:39:45, tzik wrote:
> could you use "=" for the initialization, here and elsewhere?
> I think it a bit more readable.

Done.

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc:549:
const std::string& prefix(
On 2014/07/09 06:39:46, tzik wrote:
> could you use value instead of cref to hold the return value, here and
> elsewhere?
> cref doesn't have performance advantage for this usage, and somewhat fragile.

Done.

https://codereview.chromium.org/371873003/diff/140001/chrome/browser/sync_fil...
chrome/browser/sync_file_system/drive_backend/metadata_database_index_on_disk.cc:571:
// Deletions are not run yet, so the number looks +1 larger than real.
On 2014/07/09 06:39:46, tzik wrote:
> "Deletions have not ran" or "Deletion is not completed"?

Done.

[tzik, 2014-07-10 03:52:27]

lgtm

[peria, 2014-07-10 03:53:17]

The CQ bit was checked by peria@chromium.org

[commit-bot: I haz the power, 2014-07-10 03:55:25]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/peria@chromium.org/371873003/160001

[commit-bot: I haz the power, 2014-07-10 11:06:57]

Change committed as 282305