Drew M. wrote:
> Whew, lots of text flying back and forth. I will try to condense my
> responses:
> Rick wrote:
>
>> I believe you are misinterpreting the code.
>>
> Yes sorry I did misread the code. I was too busy getting my hackles up about
> other items I mentioned previously. ;)
>
My hackles are also very strong. They get a lot of workouts. :-)
> 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. You can code up an arbitrary policy and only have to worry
> about the actual policy logic. The approach as coded, on the other hand,
> requires that if I want to create a different policy (or even just the three
> originally envisioned), I have to add the query-building logic separately
> each time, and then have to manage this if I make any changes to the Query
> class later.
>
I totally see where you are coming from. However, I was making the
InsertPolicy with an eye towards the most flexibility possible for
future use. If the InsertPolicy builds the query, then the InsertPolicy
has the power to do all kinds of things that we currently aren't
thinking of but could be incredibly useful down the road. Whether this
is likely, and whether this is worth it are up for debate.
> 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. This is what I meant by an unavoidable situation for
> developers using mysql++. A bool passed to the function would allow
> developers to avoid this situation, but it just seems awkward to me.
>
Good point. I definitely agree with the boolean argument to control
whether transactions are used, and will add that in.
> Warren wrote:
>
>> We may not want to bother creating MaxPacketPolicy for this first version.
>>
> I don't really have a horse in that race, but imo you should be able to
> determine any sort of policy required (max query string size, max elements)
> if you pass a) the Query object (or rather, the query string), and b) the
> element to insert (or rather, the string to insert into the query). My
> assumption has been that each Policy object would have internal state
> variables to assist.
>
That was definitely something I considered (and even had for a while but
took it out for some reason that escapes me now) and upon further
reflection, I think that's probably the best idea. So much thinking for
such a little piece of code! But that's called Trying to Do the Right
Thing. Besides, I suspect the policy paradigm might find its way into
other places if it works well here.
> Cheers.
>
Night Court. ;-)
