Thunderbird:Pluggable Store Migration: Difference between revisions
(Created page with "Migration is conceptually fairly easy. We iterate over the folders in the source store, create the folder in the target store, and then stream each message in the source folder t...") |
No edit summary |
||
| Line 1: | Line 1: | ||
Migration is conceptually fairly easy. We iterate over the folders in the source store, create the folder in the target store, and then stream each message in the source folder to target folder. In order to avoid file collisions, especially for file based stores like berkeley mailbox and maildir, we'll need to write to a different directory and then either point the account at the new directory, or delete the original folders from the directory. But we also have to worry about other files stored in the profile directory (msgFilterRules.dat, popstate.dat, feeds.rdf, hostinfo.dat and the like). Either we hardcode the knowledge of those files, or we clone the whole directory, delete the folders from the clone, and then stream the folders into the clone, and then change the server to point at the new clone directory. Or temporarily point the server at the clone directory, delete the folders from the original, and stream from the clone to the original, and then point the server back at the original directory. I want to be very cautious about deleting the original store, since for the pop3 case, that's the user's mail. But we have to give the user some way of deleting the original store. And I want to make unwinding from errors in the migration easier. That all points to a strategy of leaving the original server directory alone, and writing into a new directory, and then switching the server directory at the very end. | Migration is conceptually fairly easy. We iterate over the folders in the source store, create the folder in the target store, and then stream each message in the source folder to target folder. In order to avoid file collisions, especially for file based stores like berkeley mailbox and maildir, we'll need to write to a different directory and then either point the account at the new directory, or delete the original folders from the directory. But we also have to worry about other files stored in the profile directory (msgFilterRules.dat, popstate.dat, feeds.rdf, hostinfo.dat and the like). Either we hardcode the knowledge of those files, or we clone the whole directory, delete the folders from the clone, and then stream the folders into the clone, and then change the server to point at the new clone directory. Or temporarily point the server at the clone directory, delete the folders from the original, and stream from the clone to the original, and then point the server back at the original directory. I want to be very cautious about deleting the original store, since for the pop3 case, that's the user's mail. But we have to give the user some way of deleting the original store. And I want to make unwinding from errors in the migration easier. That all points to a strategy of leaving the original server directory alone, and writing into a new directory, and then switching the server directory at the very end. | ||
I think we need to create a temporary dest server object and set its directory to the target directory, set the pluggable store for the temp dest server to be the new store type, and then create a root folder for that server. That root folder will be used as the root for all the folders we create after that. | I think we need to create a temporary dest server object and set its directory to the target directory, set the pluggable store for the temp dest server to be the new store type, and then create a root folder for that server. That root folder will be used as the root for all the folders we create after that. We'll need to remove the temp server when we're done. | ||
We probably want to avoid as many notifications as possible - we won't want gloda to start indexing these new folders and messages, for example. And we don't want removing the temp server to cause any issues (like deleting the storage associated with the server). I'd like to write the migration code in js, but that could make doing any low level trickery impossible. | |||
Revision as of 23:16, 13 January 2011
Migration is conceptually fairly easy. We iterate over the folders in the source store, create the folder in the target store, and then stream each message in the source folder to target folder. In order to avoid file collisions, especially for file based stores like berkeley mailbox and maildir, we'll need to write to a different directory and then either point the account at the new directory, or delete the original folders from the directory. But we also have to worry about other files stored in the profile directory (msgFilterRules.dat, popstate.dat, feeds.rdf, hostinfo.dat and the like). Either we hardcode the knowledge of those files, or we clone the whole directory, delete the folders from the clone, and then stream the folders into the clone, and then change the server to point at the new clone directory. Or temporarily point the server at the clone directory, delete the folders from the original, and stream from the clone to the original, and then point the server back at the original directory. I want to be very cautious about deleting the original store, since for the pop3 case, that's the user's mail. But we have to give the user some way of deleting the original store. And I want to make unwinding from errors in the migration easier. That all points to a strategy of leaving the original server directory alone, and writing into a new directory, and then switching the server directory at the very end.
I think we need to create a temporary dest server object and set its directory to the target directory, set the pluggable store for the temp dest server to be the new store type, and then create a root folder for that server. That root folder will be used as the root for all the folders we create after that. We'll need to remove the temp server when we're done.
We probably want to avoid as many notifications as possible - we won't want gloda to start indexing these new folders and messages, for example. And we don't want removing the temp server to cause any issues (like deleting the storage associated with the server). I'd like to write the migration code in js, but that could make doing any low level trickery impossible.