canmove, Confirmed users
725
edits
Places/AsyncAPIsForSync: Difference between revisions
→Predecessor
Comrade693 (talk | contribs) (→Detailed Proposal: Added frecency) |
|||
| Line 239: | Line 239: | ||
We'd like to just keep it at itemIndex, due to more complicated queries or more queries. philikon says it's possible, but will follow up. --sdwilsh | We'd like to just keep it at itemIndex, due to more complicated queries or more queries. philikon says it's possible, but will follow up. --sdwilsh | ||
It's possible but all options I can think of will require serious change: | |||
# We could make bookmarks have the itemIndex instead of predecessorid. However, adding a new bookmark in a folder or moving a bookmark would invalidate a lot of other bookmarks, potentially even all, in that folder. | |||
# We could store the predecessor GUID in annotations since we now have async APIs for querying and storing these. But we would have to ensure that this annotation exists on all bookmarks first which would mean a lot of I/O on first sync, pretty much exactly the same kind of I/O that we have to do for GUIDs right now. | |||
# Instead of maintaining the ordering on the bookmarks, maintain it on their folders. Inserting or moving a bookmark would invalidate one more object, its folder (as opposed to its successor as it does now). This would mean having a childrenGUIDs array on nsIBookmarkInfo that would get/set the order of a folder's children. | |||
Both option 1 and 3 would mean a version bump for the bookmark storage. These are similarly problematic as global storage version bumps. Fortunately, we're doing one very very soon, so we could just move to the new bookmark storage version now so that it's in place when we get the async APIs. | |||
I'm personally leaning towards option 3 --philikon | |||
=== Tags === | === Tags === | ||