From: Warren Young
Date: October 31 2008 12:08am
Subject: Re: InsertPolicy and Transactions
List-Archive: http://lists.mysql.com/plusplus/8112
Message-Id: <490A4C6B.5040806@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rick Gutleber wrote:
> Does it really make sense for allow_transactions() to be part of the 
> policy or should it be a bool option passed in to insertfrom( )?
> 
> The reason I ask is because it seems silly to have to have two different 
> InsertPolicy objects that differ only in whether transactions are 
> allowed or not.

There are patterns to allow the extra attribute without creating a 
parallel class hierarchy.  I'd use traits:

	template <class AccessController = Transaction>
	class MyPolicy
	{
	public:	
		typedef AccessController access_controller;
	...

Then you could create a no-op NoTransactions class with the same 
interface as Transaction, so that MyPolicy<NoTransactions> would be 
MyPolicy without transactions.  This relieves from insertfrom() the 
burden to care about transactions:

	InsertPolicy::access_controller ac(&conn_);

A bool parameter to insertfrom() defaulting to true would make the code 
more complex.  Based on the last code you posted, it looks like you'd 
have to add 4 or so new tests to decide whether to do the transaction 
stuff.  This way, you avoid the additional tests.  This pays off in both 
understandability and run-time efficiency (the former much more 
important than the latter) because the compiler can optimize away 
NoTransactions entirely.

This also localizes concerns better: whether to use transactions or not 
*is* part of the insertion policy.

And finally, it does offer some flexibility, at the low low cost of a 
little extra template goo, which gets paid for out of other accounts: 
efficiency, code simplicity, and proper localization of concerns.