List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:October 28 2008 8:25pm
Subject:Re: Insert policy design question
View as plain text  
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.  :)
Thread
Insert policy design questionRick Gutleber27 Oct
Re: Insert policy design questionRick Gutleber27 Oct
  • Re: Insert policy design questionDrew M.27 Oct
    • Re: Insert policy design questionWarren Young27 Oct
      • Re: Insert policy design questionRick Gutleber28 Oct
        • Re: Insert policy design questionWarren Young28 Oct
          • Re: Insert policy design questionRick Gutleber28 Oct
            • Re: Insert policy design questionWarren Young28 Oct
              • Re: Insert policy design questionRick Gutleber28 Oct
                • Re: Insert policy design questionWarren Young28 Oct
                  • Re: Insert policy design questionRick Gutleber29 Oct
                    • SVN down?Rick Gutleber6 Nov
                      • Re: SVN down?Warren Young6 Nov
                  • Query::tellp( )Rick Gutleber29 Oct
                    • Re: Query::tellp( )Warren Young29 Oct
    • Re: Insert policy design questionRick Gutleber27 Oct
      • Re: Insert policy design questionDrew M.28 Oct
        • Re: Insert policy design questionRick Gutleber28 Oct
        • Re: Insert policy design questionWarren Young28 Oct
  • Re: Insert policy design questionWarren Young28 Oct
    • Re: Insert policy design questionRick Gutleber28 Oct