Pedro Lamarão wrote:
> In Wishlist we read:
>
> o Transaction support. Create a "Transaction" class, an
> object of which you create on the stack, giving it a
> reference to the Connection object. Transaction object's
> ctor calls a function on the Connection object to start
> a transaction set, and its dtor calls another function to
> commit the transaction. Also provide a "commit()" member
> function, to commit before destruction. This has a couple
> of uses. First, it's useful for avoiding exceptions coming
> from ~Transaction(), if such a thing is possible. Second,
> sometimes it's inconvenient to wait until the end of a block
> to commit the transaction, and adding artifical blocks is
> somewhat ugly.
>
> My suggestion is to not "commit on destruction" like described above.
> A transaction should not be committed if an exception is raised; it
> should be rolled back.
> Note how some implementations raise exceptions you should almost never
> catch, like win32 raising "segmentation fault" exceptions.
> The only way to commit the transaction should be through the commit()
> member function.
>
<snip>
I wonder why the constructor calls the constructor at all. I've
implemented a transaction class in Python and in PHP and I remember
while I was writing each of them I thought to myself "Too bad this isn't
C++, because then I could just subclass std::list<mysqlpp::Query>. The
constructor would take a reference to a Connection object. The
overloaded push_back() (and related members) would re-assign the Query
object's connection. Finally, I would add a member execute() that
executed the queries inside a transaction.
I'm mentioning this, not to criticize your efforts, but because I will
be implementing this in the semi-near future. Would anyone on the list
be interested in it once it's done?
Drew Vogel
