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