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

Rick Gutleber wrote:
> I wonder if there is an option to explicitly choose to write 
> quoted output to a stream that isn't a Query.

No, but I'm open to proposals of how to do it.

Perhaps you could do it with a manipulator, to mark a particular 
insertion as being a SQL build operation.  It wouldn't have to be a new 
manipulator; something like operator<<(quote_typeN, value_list) could do 
it.  This is just a vague concept, though.  I don't know how it would 
actually work.

Another way would be to have an ostringstream work-alike that the 
current manipulators would recognize.  SQLStream?

> I had a hard time deciding what should be done in insertfrom( ) and what 
> should be done in the InsertPolicy,

Yes, factoring this will take some thought.  As I wrote elsewhere, I do 
think the policy object should do little more than answer questions for 
insertfrom().  I don't see a need for it to contain any SQL code.

> the only way to see what you've 
> written so far is to call the str( ) method which involves constructing 
> a std::string and (IIUC) copying the entire contents of the string, 
> which by definition is likely to be very long.

Hmmm...I was expecting that we could use ostream::tellp().  That won't 
work on Query itself, though, because it no longer is-an ostream.  I 
don't see that std::stringbuf has an equivalent mechanism, though that 
calls into question how ostringstream::tellp() works.

Perhaps it's another argument in favor of SQLStream?

> I do like the idea that the InsertPolicy actually builds the query 
> string because there are other possibilities for what it could do, one 
> of which as I suggested before is to deal with auto-increment IDs.  

I must have missed that.  Why would a policy object care about 
auto-increment fields?  Just set them to NULL in the container, which 
tells MySQL to make up a value instead of use what was passed in.

> ...in order for InsertPolicy to be 
> as open-ended as possible, it seemed like the way to approach it.

But let's also not over-engineer it.  Flexibility is wonderful when it 
costs nothing.

> I apologize if this simple task is generating a ton of questions.

*shrug*  The alternative is for you to send us something that we won't 
like, which we reject out of hand.  :)