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


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