PTAL.
As I mentioned on chat, I'm realizing this id mapping doesn't work during a shadow write mode. This kind of breaks most all of the ideas.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
for (const auto& child : tab_collection->GetChildren(pass_key_)) {
This might be an eh suggestion, but I think our service probably shouldn't be doing the iteration itself.
I think our tree crawling should probably be done by a class that exposes it. Maybe a flat iterator that only exposes the direct children (ie no children of children) at the current level?
base::PassKey<TabStateStorageService> pass_key) const {
Is there any way we can combine these via a shared `CollectionCrawler` class or something?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
base::PassKey<TabStateStorageService> pass_key_{};
Same here. I still feel like we shouldn't keep this here, and this should be managed by another object
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Same here. I still feel like we shouldn't keep this here, and this should be managed by another object
Done
for (const auto& child : tab_collection->GetChildren(pass_key_)) {
This might be an eh suggestion, but I think our service probably shouldn't be doing the iteration itself.
I think our tree crawling should probably be done by a class that exposes it. Maybe a flat iterator that only exposes the direct children (ie no children of children) at the current level?
Done
base::PassKey<TabStateStorageService> pass_key) const {
Is there any way we can combine these via a shared `CollectionCrawler` class or something?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
repeated int32 storage_id = 1;
A comment on here for what this represents and how it is generated might be helpful (both now and asiprationational).
next_storage_id_ = max_id + 1;
This might also need to change right? Add TODO?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
A comment on here for what this represents and how it is generated might be helpful (both now and asiprationational).
Done
This might also need to change right? Add TODO?
Totally needs to change. Ideally we stop dealing with TabStates entirely, and just deal with collections.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
3 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: chrome/browser/tab/tab_state_storage_service.cc
Insertions: 4, Deletions: 0.
@@ -111,6 +111,10 @@
}
}
}
+ // TODO(https://crbug.com/427254267): While this avoids collisions and does
+ // set up a mapping for live Tab objects from Java, doesn't interact nicely
+ // with collections objects mappings. Ideally this will be fully replaced as
+ // soon as we can create and pass up collections objects on start up.
next_storage_id_ = max_id + 1;
std::move(callback).Run(std::move(tab_states));
}
```
```
The name of the file: chrome/browser/tab/protocol/children.proto
Insertions: 5, Deletions: 0.
@@ -9,5 +9,10 @@
option java_package = "org.chromium.chrome.browser.tabs.proto";
message Children {
+ // Used to serialize a list of ids into a single db blob cell. The storage id
+ // is created by the storage system and used to map in memory objects to rows
+ // in the database. Note that before this system is authoratative for reads,
+ // this mapping cannot be recreated on start up, and will require rebuilding
+ // (and deletion of the whole db) to fix.
repeated int32 storage_id = 1;
}
```
[Persist] Maintain an in memory map of handles to storage ids.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |