Jonathan Feally wrote: > For the messageblks to mimeparts migration - I don't really care when it > is dropped. So 2.5 is a possibility. As long as 2.4 has a check if table > exists at daemon startup so that the code to read from that table is > completely skipped if absent. I think that once that functionality is > there, the create_tables should no longer include it. Optionally, a > config file option that disables reading from the messageblks table. If > the value is missing, then it will work as designed now. Once the table > is dropped from the code, that option will go unused.
No rush. The messageblks code is currently *only* used for full message retrieval, when a physmessage.id can't be found in mimeparts. Imap-search doesn't support messages in the old storage. So that should encourage 2.4 users to exercize the migration to mimeparts storage. Building a slow, unobtrusive, low-impact migration path will make things painless. One lesson from the 2.3.5-2.3.6 migration: changes to messageblks are potentially /very/ expensive, and there's simply no case for them. I migrated my own dbmail server today from 2.3.5 to git-head, and I stopped the sql migration after the database had been crunching for over an hour to simply change the width of the messageblks_idnr column. That was downtime no production server should have to suffer. Something a definitely won't be able to tolerate on production environments. > > As far as a simpler schema, using the views will suffice for now, and > they can be dropped very fast if we go back to a single all-in-one query > later. Since we are adding views to do the header 3-way join, why not > create a view for search that doesn't have the where headername= and > then provide the where headername= in the search function? Call it > dbmail_search_header or something like that. Mmm, not sure I follow you there. Sounds more like a stored procedure to me. > > I only see one outstanding issue, and that is the patch I sent you to > finish dropping the auto_* tables usage in the code. What patch? I'm not sure I actually saw that one. Stripping out execute_auto_ran would do the trick, right? -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
