List:MySQL++« Previous MessageNext Message »
From:Rick Gutleber Date:October 28 2008 9:04pm
Subject:Re: Insert policy design question
View as plain text  
Warren Young wrote:
> 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.


I figured something like this would be possible.  I'll put some thought 
into it if I get a chance.


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

Well, that's not a bad idea either, but you would then be limited that 
one particular stream, or any others you bother to derive new classes 
for.  On the other hand, ostringstream is probably good enough for 
anything you might need.  If something like that were done, then maybe 
you could derive Query from that and change all the manipulators to use 
SQLStream instead of Query.  I mean, Query only seems to derive from 
ostream so you can take advantage of the << operators for composing 
queries.  An ostringstream would do that just fine.


>
>> 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.


But this raises a bit of a problem because the less the policy object 
actually does the more you have do things that serve no purpose except 
to tell the policy what you're doing.  I'd really wanted to avoid that.  
For instance, you can't limit the INSERT statement based on the number 
of objects inserted unless you are telling the policy when you are 
inserting objects.  In fact, if all you are doing is asking it questions 
by passing in a Query reference and a RowT object then the _only_ way 
the policy can make decisions is by looking at the contents of the SQL 
statement buffer, which we've talked about elsewhere.

At this point I have to wonder if there's anything useful an 
InsertPolicy could possibly do _except_ checking the length unless it 
were to parse the SQL, which is just silly.


>> 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?


Maybe so, but then again if we can only make decisions based on the SQL 
statement length there really doesn't seem to be any reason to have the 
InsertPolicy at all.


>
>
> I must have missed that.  Why would a policy object care about 
> auto-increment fields?  


It wouldn't.  It was just an idea I had of utilizing the policy's 
ability to build SQL.  The more I think about the InsertPolicy the more 
I wonder if there is anything useful it could do other than what the 
default ones we defined do.


> Just set them to NULL in the container, which tells MySQL to make up a 
> value instead of use what was passed in.


I've run into this before.  You would have to make the auto-increment 
field null-able in the SSQLS declaration, which I hadn't done because it 
wasn't a null-able field.  It's smack-you-in-the-face obvious in 
retrospect, but it had never occurred to me and I found it very 
frustrating to deal with.  If that's mentioned in the docs, I simply 
missed it.

>
>> ...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.



Very true.  Like I've said (or implied) several times, I'm not entirely 
sure that level of flexibility was really useful.


>
>> 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.  :)
> .


Well, then we're on the same page.  MySQL++ is one of the few 3rd party 
libraries I've ever used in 20+ years that actually seems to have had 
some serious thought put into its design, interface, and even 
philosophy.  Most libs seem to just accrete features until they 
(hopefully) become useful and are often inconsistent, clumsy or 
otherwise suboptimal.  (translation:  I did Windows development for many 
years).



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