On Mar 19, 12:51 am, Mark Ramm <[email protected]> wrote: > Well, this is definitely something we should document, but as a > transaction manager, it has two choices, always create a transaction > and commit it even when it's not needed, or only do it when needed. > And the second should reduce DB overhead considerably,
Are you sure there's any significant overhead? If the commit turns out to be a no-op on the db engine side, chances are it will return immediately. Besides, there are situations where you don't even care about the overhead (my original problem was with an upgrade/downgrade script). Perhaps the API should be split in two: - transaction.commit() does an unconditional commit - transaction.speculative_commit() does a commit only if it thinks it's necessary (or, alternatively, transaction.commit(speculative=True)) In any case, I think the default should be safe. Correctness is important, especially when we're talking about a database. (and if I want raw speed and don't really care about transactions, I can use MySQL with non-transactional tables...) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
