List:MySQL++« Previous MessageNext Message »
From:Drew Vogel Date:March 8 2006 6:21pm
Subject:Re: Transaction class design in Wishlist
View as plain text  
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


Thread
Transaction class design in WishlistPedro LamarĂ£o6 Mar
  • Re: Transaction class design in WishlistWarren Young6 Mar
    • Re: Transaction class design in WishlistPedro LamarĂ£o6 Mar
      • Re: Transaction class design in WishlistWarren Young6 Mar
      • Re: Transaction class design in Wishlistdon thompson6 Mar
        • Re: Transaction class design in WishlistWarren Young6 Mar
          • Re: Transaction class design in WishlistWarren Young6 Mar
  • Re: Transaction class design in WishlistDrew Vogel8 Mar
    • Re: Transaction class design in WishlistWarren Young8 Mar