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

Drew M. wrote:
> Exactly. If the policy just dictates when it is ok to add more elements and
> when it is not, you don't have to replicate the query-building logic in each
> Policy class. 

I think I agree.

I called them insertion *policy* classes, not inserter classes.  I don't 
see that objects of these classes should do much more than just answer 
questions for Query::insertfrom(), like "can insert" or "can use 
transactions".  The answers guide it in building the SQL.

> My problem isn't so much with employing transactions, rather it's that mysql
> transactions can't, to my knowledge, be nested. So, if you have a complex
> transaction and then call Query::insertfrom(), you have committed your
> previous statements regardless of whether Query::insertfrom() fails or not,
> and can't rollback.

How likely is it you'd be in the middle of building a transaction and 
then want to go and insert a whole container full of records as part of 
it?  It seems to me that this feature is typically doing something 
self-contained.

Certainly it *can* happen.  But *will* it?

One solution, which would unfortunately have to wait for v4, would be to 
add a private flag to Connection (or DBDriver), toggled by Transaction, 
indicating whether we're in the middle of a transaction.  insertfrom() 
could check that before deciding whether to start a new transaction. 
Or, better, Transaction could just do nothing if it sees we're already 
in the middle of a transaction.  Unfortunately, adding member variables 
changes object sizes, and so breaks the ABI.  I'll add it to the v4 
section of the Wishlist anyway.