From: Warren Young
Date: October 27 2008 10:56pm
Subject: Re: Insert policy design question
List-Archive: http://lists.mysql.com/plusplus/8077
Message-Id: <49064724.6000505@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Drew M. wrote:
> The other code in query.h uses an overloaded << operator with a Query object
> on the left side. Your code uses an ostringstream, which is why the behavior
> is different.

Yes.  We may not want to bother creating MaxPacketPolicy for this first 
version.  It may be too difficult to implement to justify the small 
safety it provides over the easier to implement SizeThresholdPolicy. 
The latter doesn't need a separate stream object; you can insert the 
data straight into *this, as Query::insert() does.

> I think you should take the transaction calls out, similar to the other
> insert-ish methods. It should be up to the end-developer to decide whether
> or not to employ transactions, and using them in library code might cause
> unintended (and unavoidable) effects for end-developers.

I understand your worry, but keep in mind, Query::insertfrom(container, 
policy) will need to make several queries to insert a large container. 
If any one of them fails, do you really want to leave half of the 
container's data still in the DB?  Query::insert() either succeeds or 
fails; it never inserts half a record.  I think Query::insertfrom() 
should behave the same way, at least by default.

Perhaps each policy class should have an optional "no transactions" 
boolean parameter on its ctor, defaulting to true.

Also keep in mind that BEGIN, COMMIT and ROLLBACK are no-ops on MySQL 
when the underlying DB engine doesn't support transactions.