1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
// Copyright 2018 The Chromium Authors
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
syntax = "proto2";
package sync_pb;
import "components/sync/protocol/data_type_state.proto";
import "components/sync/protocol/entity_metadata.proto";
option java_multiple_files = true;
option java_package = "org.chromium.components.sync.protocol";
option optimize_for = LITE_RUNTIME;
// Corresponds to a single bookmark id/metadata pair.
message BookmarkMetadata {
// Bookmark local id.
optional int64 id = 1;
// Bookmarks sync metadata.
optional EntityMetadata metadata = 2;
}
// Sync proto to carry the sync metadata for the bookmarks model. It is used for
// persisting and loading sync metadata from disk.
message BookmarkModelMetadata {
// Bookmark global metadata.
optional DataTypeState data_type_state = 1;
// A set of all bookmarks metadata.
repeated BookmarkMetadata bookmarks_metadata = 2;
reserved 3;
reserved 4;
reserved 5;
// Indicates whether the reupload of bookmarks has been triggered such that
// they include fields like `type`, `unique_position` and `parent_guid`, which
// means that their sequence number has been increased (independently of
// whether the commit has succeeded or even started).
// TODO(crbug.com/40780588): remove this code when most of bookmarks are
// reuploaded.
optional bool bookmarks_hierarchy_fields_reuploaded = 6;
// Number of remote updates that were ignored because the parent folder could
// not be determined since sync (bookmark sync) started (since initial sync,
// including initial sync itself). Note that this excludes updates
// representing changes (moves) to existing/tracked bookmarks (i.e. the parent
// folder used to be known, but the new one specified in the update isn't).
//
// Only a minority of users should have a non-zero value, due to a) corrupt
// data, reasons unknown; or b) permanent folders that were unsupported at the
// time the update was received (either for the permanent folder itself or for
// descendants). The absence of this field should be interpreted as 'unknown',
// which roughly means the counter wasn't supported by the browser -M77 or
// below- at the time sync was enabled (it also means, it will remain
// 'unknown' until initial sync is exercised, e.g. sync disabled and
// reenabled).
optional int64 num_ignored_updates_due_to_missing_parent = 7;
// See field above. Among such ignored updates, this field tracks which was
// the highest server version. This may be useful -in the future- to get a
// sense of "time" (or, since versions are opaque to the client, at least a
// notion of ordering with respect to other updates). The absence of this
// field should be interpreted as 'unknown' and does not distinguish the
// case between a) no updates ignored; and b) field wasn't supported at the
// time the last update was ignored. To distinguish between these two, the
// field above can be used.
optional int64 max_version_among_ignored_updates_due_to_missing_parent = 8;
// Indicates whether the count of remote updates during the latest initial
// merge exceeded the bookmark limit. This field is mutually exclusive to all
// the other fields and is managed completely by the processor.
// TODO(454302754): Remove this field once
// `last_initial_merge_remote_updates_exceeded_limit_timestamp_windows_epoch_micros`
// is stable.
optional bool last_initial_merge_remote_updates_exceeded_limit = 9;
// The timestamp (in microseconds) when the above limit was exceeded.
optional int64
initial_merge_remote_updates_exceeded_limit_timestamp_windows_epoch_micros =
10;
}
|
