Closed Bug 1071505 Opened 10 years ago Closed 10 years ago

Expose constant root GUIDs

Categories

(Toolkit :: Places, defect)

defect
Not set
normal
Points:
8

Tracking

()

RESOLVED FIXED
mozilla36
Iteration:
36.2

People

(Reporter: mak, Assigned: mak)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files, 1 obsolete file)

We need a quick way to access the roots guids, and it should be ideally synchronous. Moreover we also would like to get rid of the moz_bookmarks_roots table. A possible implementation idea could be to enforce special GUIDs on the roots, for example "root________" "menu________" "toolbar_____" "unfiled_____" these would be valid guid, we might use them everywhere, even hardcoded, we could expose them synchronously. The database constraint would ensure we cannot have duplicates and we could likely get rid of moz_bookmarks_roots.
Blocks: 1071511
Points: --- → 8
Flags: qe-verify-
Flags: firefox-backlog+
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Iteration: --- → 36.2
Attached patch patch v1 (obsolete) (deleted) — Splinter Review
Attached patch tests v1 (deleted) — Splinter Review
The size of this patch looks scary cause I decided to add 1 db per schema version, for future reference. All tests are passing so far, but I'm having issues (warnings) with a migration test that for whatever reason doesn't finalize statements properly in Sqlite.jsm The test is test_current_from_v24.js and the issue is activated when I use PlacesUtils.bookmarks.eraseEverything() in it. I fear there might be some race condition between Sqlite.jsm and Places shutdown :(
Attached patch patch v1 (deleted) — Splinter Review
I will file a separate bug for the shutdown problem, there's no reason to block this change on that. so let's start the review process now, I don't plan to add more to this patch.
Attachment #8514395 - Attachment is obsolete: true
Attachment #8514554 - Flags: review?(mano)
Comment on attachment 8514401 [details] [diff] [review] tests v1 Review of attachment 8514401 [details] [diff] [review]: ----------------------------------------------------------------- not particularly interesting changes
Attachment #8514401 - Flags: review?(mano)
Comment on attachment 8514554 [details] [diff] [review] patch v1 Add a note that tagsGuid isn't going to grow old. This looks very good otherwise. Make sure to try-run this.
Attachment #8514554 - Flags: review?(mano) → review+
Comment on attachment 8514401 [details] [diff] [review] tests v1 rs=mano. Feel free (you really don't have to!) to fix all those callers in test_async_transactions.js (there's rootGuid = yield in almost every test there). But if you so, wait for bug 982115 to land first.
Attachment #8514401 - Flags: review?(mano) → review+
Richard, from my code checks looks like Sync won't have issues with this change, but I'd be more comfortable if you could evaluate it as well. What we are doing here, is just changing the roots (menu, toolbar, unfiled) guids to new constant values. From what I can tell Sync never accesses the root guids and always compares ids to find roots.
Flags: needinfo?(rnewman)
Comment on attachment 8514554 [details] [diff] [review] patch v1 Review of attachment 8514554 [details] [diff] [review]: ----------------------------------------------------------------- This should be fine for Sync, so long as the old method of using parent IDs (not GUIDs) still works. Sync hits the DB to find the GUID for a record's numeric parent ID. If it's one of the numeric IDs for a root, it skips that and uses a special faux-GUID (e.g., "toolbar"). ::: toolkit/components/places/Bookmarks.jsm @@ +107,5 @@ > + menuGuid: "menu________", > + toolbarGuid: "toolbar_____", > + unfiledGuid: "unfiled_____", > + tagsGuid: "tags________", > + Sync uses the following for these: // Special IDs. Note that mobile can attempt to create a record on // dereference; special accessors are provided to prevent recursion within // observers. guids: ["menu", "places", "tags", "toolbar", "unfiled", "mobile"], Is there a reason you're using underscore as padding? I didn't think that was a valid character for the GUIDs we use?
(In reply to Richard Newman [:rnewman] from comment #9) > ::: toolkit/components/places/Bookmarks.jsm > @@ +107,5 @@ > > + menuGuid: "menu________", > > + toolbarGuid: "toolbar_____", > > + unfiledGuid: "unfiled_____", > > + tagsGuid: "tags________", > > + > > Sync uses the following for these: > > // Special IDs. Note that mobile can attempt to create a record on > // dereference; special accessors are provided to prevent recursion within > // observers. > guids: ["menu", "places", "tags", "toolbar", "unfiled", "mobile"], these are not valid guids, afaict it's just made up strings Sync uses as placeholders. Any new style GUID must be 12 chars. > Is there a reason you're using underscore as padding? I didn't think that > was a valid character for the GUIDs we use? "_" is a valid char, based on http://mxr.mozilla.org/mozilla-central/source/toolkit/components/downloads/SQLFunctions.cpp#50 and http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/Helpers.cpp#295 Basically, any char that is invalid for an url, like "+" or "/", gets converted to "-" or "_" in the guids implementation, so "_" looks like a good placeholder here.
and I choose _ cause the alternatives don't sound any better (numbers, alphabet or -)
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #10) > these are not valid guids, afaict it's just made up strings Sync uses as > placeholders. > Any new style GUID must be 12 chars. Correct; these only go to the server and other implementations. > Basically, any char that is invalid for an url, like "+" or "/", gets > converted to "-" or "_" in the guids implementation, so "_" looks like a > good placeholder here. Sounds good. Thanks for clarifying.
Flags: needinfo?(rnewman)
Blocks: 1143712
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: