Hi !
Jon Ribbens wrote:
On Tue, May 15, 2007 at 06:39:21PM -0500, Kenneth Loafman wrote:
Interesting... guess the intent was a disconnect that would break code
trying to work on MySQL, regardless of engine selected. That decision
makes it two products, MySQL/MyISAM and MySQL/InnoDB with different
semantics. Yes, you can work around it, but its not transparent.
I think the purist's response to that would be that it is a bug in
MySQL that MySQL does not support transactions always. But anyone
for whom that is a problem probably isn't on this list ;-)
Well, sometimes I like to take the purist's point.
In any case, InnoDB is a transaction-oriented table handler, and users
of it should be aware of that fact.
It *has* a different semantics from MyISAM.
IMNSHO, the performance gain which can be achieved by "autocommit" does
not outweigh the risks involved with it:
If you accidentally have autocommit enabled where really several SQL
statements should form a transaction, your testing will never show a
problem until the application (or the server, or the communication)
breaks after executing this series only partially.
And also IMNSHO, it is better to have statements not executed at all
(because they will be rolled back due to the lack of commit) than to
have a partial execution of a transaction, as that would break the
consistency of the database.
So IMO it is a good decision not to support autocommit in an API, in
order to prevent users from falling into this trap.
This does explicitly *not* refer to interactive tools, where it is much
more common that individual changes to the database are really
independent of each other. Most users will forget to hit a "commit"
button, so the tool may offer it.
Regards,
Jörg
--
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
