Closed
Bug 1071505
Opened 10 years ago
Closed 10 years ago
Expose constant root GUIDs
Categories
(Toolkit :: Places, defect)
Toolkit
Places
Tracking
()
People
(Reporter: mak, Assigned: mak)
References
(Blocks 2 open bugs)
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
asaf
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
asaf
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•10 years ago
|
Blocks: placesAsyncBookmarks
Assignee | ||
Updated•10 years ago
|
Points: --- → 8
Flags: qe-verify-
Flags: firefox-backlog+
Updated•10 years ago
|
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Iteration: --- → 36.2
Assignee | ||
Comment 1•10 years ago
|
||
Assignee | ||
Comment 2•10 years ago
|
||
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 :(
Assignee | ||
Comment 3•10 years ago
|
||
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)
Assignee | ||
Comment 4•10 years ago
|
||
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 5•10 years ago
|
||
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 6•10 years ago
|
||
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+
Assignee | ||
Comment 7•10 years ago
|
||
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)
Assignee | ||
Comment 8•10 years ago
|
||
Comment 9•10 years ago
|
||
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?
Assignee | ||
Comment 10•10 years ago
|
||
(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.
Assignee | ||
Comment 11•10 years ago
|
||
and I choose _ cause the alternatives don't sound any better (numbers, alphabet or -)
Comment 12•10 years ago
|
||
(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)
Assignee | ||
Comment 13•10 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/ad5327aa82fd
https://hg.mozilla.org/integration/fx-team/rev/bbd631108069
Flags: in-testsuite+
Target Milestone: --- → mozilla36
https://hg.mozilla.org/mozilla-central/rev/ad5327aa82fd
https://hg.mozilla.org/mozilla-central/rev/bbd631108069
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•