Drew M. wrote:
> Exactly. If the policy just dictates when it is ok to add more elements and
> when it is not, you don't have to replicate the query-building logic in each
> Policy class.
I think I agree.
I called them insertion *policy* classes, not inserter classes. I don't
see that objects of these classes should do much more than just answer
questions for Query::insertfrom(), like "can insert" or "can use
transactions". The answers guide it in building the SQL.
> My problem isn't so much with employing transactions, rather it's that mysql
> transactions can't, to my knowledge, be nested. So, if you have a complex
> transaction and then call Query::insertfrom(), you have committed your
> previous statements regardless of whether Query::insertfrom() fails or not,
> and can't rollback.
How likely is it you'd be in the middle of building a transaction and
then want to go and insert a whole container full of records as part of
it? It seems to me that this feature is typically doing something
self-contained.
Certainly it *can* happen. But *will* it?
One solution, which would unfortunately have to wait for v4, would be to
add a private flag to Connection (or DBDriver), toggled by Transaction,
indicating whether we're in the middle of a transaction. insertfrom()
could check that before deciding whether to start a new transaction.
Or, better, Transaction could just do nothing if it sees we're already
in the middle of a transaction. Unfortunately, adding member variables
changes object sizes, and so breaks the ABI. I'll add it to the v4
section of the Wishlist anyway.
