On Thu, 2003-10-16 at 11:55, Chris Mason wrote: > There's a lot more to using transactions than BEGIN/COMMIT. The current > code orders operations such that transactions are not purely required. > When inserting messages it sets the unique_id last (as a kind of > informal commit), does rollback manually when some part of the insert > fails, etc. > > A real transactional system would let the database do all of that. My > patch only addresses a performance aspect with mysql transactional > tables...every write triggers a commit. Enclosing them in a transaction > does one commit for the whole group instead.
I agree with all the above 100%, my biggest gripe with the dbmail design is that it does a lot of work to deal with mysql limitations. I think that's a bad design decision. Use the database to do what it does best, which is maintain data consistency for you. > Inserting a huge message as an atomic unit might not be the best idea, > I'm not sure how well mysql will cope with it. Can't speak to that, but I wouldn't think it's a problem, I don't expect to recieve isos for CD via email. I would imagine that mysql can handle several MB emails in one transaction, especially since the msg_blocks table splits it up into several small inserts.