Drew M. wrote:
> The other code in query.h uses an overloaded << operator with a Query object
> on the left side. Your code uses an ostringstream, which is why the behavior
> is different.
Yes. We may not want to bother creating MaxPacketPolicy for this first
version. It may be too difficult to implement to justify the small
safety it provides over the easier to implement SizeThresholdPolicy.
The latter doesn't need a separate stream object; you can insert the
data straight into *this, as Query::insert() does.
> I think you should take the transaction calls out, similar to the other
> insert-ish methods. It should be up to the end-developer to decide whether
> or not to employ transactions, and using them in library code might cause
> unintended (and unavoidable) effects for end-developers.
I understand your worry, but keep in mind, Query::insertfrom(container,
policy) will need to make several queries to insert a large container.
If any one of them fails, do you really want to leave half of the
container's data still in the DB? Query::insert() either succeeds or
fails; it never inserts half a record. I think Query::insertfrom()
should behave the same way, at least by default.
Perhaps each policy class should have an optional "no transactions"
boolean parameter on its ctor, defaulting to true.
Also keep in mind that BEGIN, COMMIT and ROLLBACK are no-ops on MySQL
when the underlying DB engine doesn't support transactions.
