325176 - Ensure Places Migrates Correctly

Status: RESOLVED INVALID

(Firefox :: Bookmarks & History, defect, P1)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

We need to do a full test of our various migration components on a set of existing profiles, rather than testing each piecemeal. This is important since this is the codepath our users will be going down, vs our testing so far in our fresh debug profiles. 

This might be best done after the stability issues with the database are shaken down.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Bookmarks from existing profiles don't appear to be imported. I created a new profile with a current trunk build, then I used the places-enabled build with the same profile.  The default home page still works, and the history was picked up. However, the bookmarks I created are gone in favor of the default bookmarks from the build.

If I browse to the profile directory, bookmarks.html is still there intact.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Attachment: The profile I'm using

This is a zip archive of the profile I'm using to reproduce this with.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

On second check, it doesn't appear the history was imported correctly either.

Comment 4

[Brian Ryner (not reading)]

The profile as attached here already has a storage.sdb with all of the tables, so it's not surprising that nothing migrates.  Without a storage.sdb, it all migrates fine for me.

Comment 5

[Brian Ryner (not reading)]

One idea for testing this in an automated / robust way would be to ship the old implementations (perhaps locked down to not do any file writes) and write a verifier that compares the data from the two sources.  If we detect a discrepency, we could give the user instructions (or even an automated way) for sending a report that contains whatever file failed to import correctly.  We'd obviously have to spell out the privacy implications of that.

If that's too heavyweight, we could just add some extra error checking to the new implementation and write a verifier that checks the internal consistency of the database (all id cross-references are valid, no bookmark holes, etc) and generate a report when something fails.

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

I'm just going to mark this as "not-a-bug" and let the real bugs flow in after we turn this on for testing. 

Comment 7

[Brian Ryner (not reading)]

Attachment: speed up import

This makes a couple of improvements:

- put a transaction around the in-memory links table updating (helps a lot)
- defer creating some of the indexes until after import (helps a bit)

Comment 8

[Brett Wilson]

Comment on attachment 211941 [details] [diff] [review]
speed up import

>+  mozIStorageConnection* GetMemoryStorageConnection()
>+  {
>+    return mMemDBConn;
>+  }

Can you put this in an #ifdef? Also, mDBConn and InitMemDB now that we're defining IN_MEMORY_LINKS in the module instead of in the .cpp.

It looks like you call InitMemDB from Init even when IN_MEMORY_LINKS is not used

Comment 9

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv