On 08/27/2013 11:51 AM, Thomas Raschbacher wrote:
> I know what you mean about atomic DB stuff in code .. can be quite a pain.
> I am not entirely sure what is done during the migration, so can'T judge
> about doing it in an SP ^^
Messages are basically retrieved (using the old messageblks storage) and
stored again (using the mimeparts storage).
The whole procedure is wrapped in a transaction:
BEGIN;
Fetch a limited number of physmessage_ids from the messageblks table.
For each physmessage_id:
retrieve message
store message
if store is successful:
delete message rows from messageblks
COMMIT;
All in src/maintenance, do_migrate
> I do have some experience with Stored Procedures, so if you needed
> something specific (Postgres mostly) I can probably help. I had to write
> a lot of Stored Procedured (for MS SQL though) in one of my previous
> jobs (some of them were ridiculously long because they had grown which
> is also a pain of course).
Main problem is (in general when dealing with DBMail) is that such
procedures would have to be written and tested on all three backends.
Patches that only deal with one specific backend are rejected. I don't
expect anyone to deal with Oracle, but the other three are open-source
and readily available.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/[email protected]/+31.85.877.99.97
________________________________________________________________
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
