On Dienstag 09 Juni 2009 Aaron Stone wrote:
One concern I remember was about the running configuration
being different from the values in the database; basically, did you
manually alter the database config values without bouncing the
daemon?
A dbmail-config utility that managed this table for
On Montag 08 Juni 2009 Jonathan Feally wrote:
I'm not sure if a per user
script to move messages is the best approach. Probably just need to
add it to dbmail-util to move them from the old structure to the new
one. We don't even need to change the phymessage_id, just insert the
mimeparts,
Michael Monnerie wrote:
But how do you delete messageblks without their entire message? There
are lots of constraints all over the place. You'd need to redefine
those. OK, as there will be no more old inserts, it shouldn't really
hurt to loose those.
If per-user is not good - what would
Aaron Stone wrote:
We dropped the dbmail_config table very early on, between DBMail 1.1 and
1.2. There were good reasons to have a configuration file, and once things
started going in there, having two places to configure the daemons seemed
like a bad idea. One concern I remember was about
Jonathan Feally wrote:
The constraints are set such that the dbmail_phymessage row would need
to be deleted to cascade a delete in the dbmail_messageblks. So simply
inserting the unique parts in the mimeparts, then insert the part_id's
into partlists, update header cache, then delete the
Michael Monnerie wrote:
On Montag 08 Juni 2009 Jonathan Feally wrote:
I'm not sure if a per user
script to move messages is the best approach. Probably just need to
add it to dbmail-util to move them from the old structure to the new
one. We don't even need to change the phymessage_id, just
Paul J Stevens wrote:
Jon,
there's no need to update the header cache.
Ok, I wasn't sure. I didn't think it needed to be done. Throttling the
movement would be difficult. While the processing could be done on
another box separate of the production daemons, the database load and
disk
Paul J Stevens wrote:
Other than the lack of any perceivable added benefit (for me at least),
my main objections are with regard to change management and security.
For example, I like being able to stick /etc/dbmail/ into a git
repository. And I *really* don't want my ldap bind_dn parameters
