List:Summer of Code« Previous MessageNext Message »
From:Joseph Lukas Date:August 10 2009 6:15pm
Subject:Re: Fwd: GSoC Week 14 - August 2 - August 9 per query variable
settings
View as plain text  
A quick question on 9. SET STATEMENT var1=... FOR SET SESSION var=...
I thought about this one for a little bit in which you change the same
variable 2 times.  This statement I know would execute as: it would
store the current variable, the SET SESSION would override the
temporary set but would return to the old setting at the end not the
one after the FOR.  I am unsure if I should have coded for this to
change to the SET SESSION after the running of the function.  This
would also be true if a stored procedure contained a SET SESSION that
had a SET STATEMENT on the outside of execute. I figured that this
would have been described in how the function works and not to do it.
I would believe that the same variable would not be changed in the
statement in 99.99% of the queries. This would be unless they wanted
to override the SET inside the procedure and return to original then
they would use a SET STATEMENT which may be useful in rare cases.

On Mon, Aug 10, 2009 at 12:53 AM, Sergei Golubchik<serg@stripped> wrote:
> Hi, Joseph!
>
> On Aug 09, Joseph Lukas wrote:
>> KEY ACCOMPLISHMENTS LAST WEEK
>> Finished most of test cases so far.  I am unsure of other areas to
>> test.  I have tested to make sure that the variable is set during the
>> statement execution and change back.  I have tested with various other
>> statements.  Some most likely to be used others more random and highly
>> unlikely just to vary it up. I have also tested each system variable
>> type in the various cases.
>
> good
>
>> KEY TASKS THAT STALLED LAST WEEK
>> Not sure if all testing is done.
>
> few comments to your statement_set.test :
>
> more functional tests please, that is, more tests to show that the value
> is set, like SET STATEMENT ... FOR SHOW VARIABLES or
> SET STATEMENT ... FOR SELECT @@variable. In particular, consider cases
> like
>
>  1. prepared statements. just like the one you already have
>     but with SHOW VARIABLES or SELECT @@variable
>  2. prepared statements. SET STATEMENT ... FOR PREPARE and
>     SET STATEMENT ... FOR EXECUTE. The first SET should not affect the
>     output of SHOW VARIABLES, I suppose, the second - should.
>  3. prepared statements. A mix of 1 and 2: SET STATEMENT ... FOR EXECUTE
>     and another SET STATEMENT inside the prepared statement. One test
>     where two SETs modify the same variable, another - different
> variables.
>  4. stored routines. SET STATEMENT *inside* a stored procedure. Or two
>     SET STATEMENT, on different statements.
>  5. stored procedure. SET STATEMENT ... FOR CALL ...
>  6. mix of 4 and 5, like in
>     CREATE PROCEDURE p1 ... BEGIN
>        SELECT @@var1, @@var2;
>        SET STATEMENT var1=... FOR SELECT @@var1, @@var2;
>        SELECT @@var1, @@var2;
>        SET STATEMENT var2=... FOR SELECT @@var1, @@var2;
>        SELECT @@var1, @@var2;
>     END;
>
>     SELECT @@var1, @@var2;
>     SET STATEMENT var1=... FOR CALL p1()
>     SELECT @@var1, @@var2;
>  7. compound statement:
>     SET STATEMENT var1=... FOR BEGIN ... END
>  8. how it affects parsing:
>
>     SET STATEMENT sql_mode='ansi' SELECT * FROM "t1"
>     SET STATEMENT sql_mode='ansi' PREPARE stmt1 FROM 'SELECT * FROM "t1"'
>
>     the first one is an error, I suppose, but the second is ok
>
>  9. SET STATEMENT var1=... FOR SET SESSION var=...
>  10. like 9 but in a stored procedure:
>     CREATE PROCEDURE p1 ... BEGIN
>        SELECT @@var1;
>        SET SESSION var1=...;
>        SELECT @@var1;
>     END;
>
>     SELECT @@var1;
>     SET STATEMENT var1=... FOR CALL p1()
>     SELECT @@var1;
>
> Just a few ideas (not all of them are mine) :)
>
>> TASKS IN THE UPCOMING WEEK
>> Documentation, documentation, documentation. I am unsure what
>> documentation is to be done.  I am assuming the manual entry for how
>> to use the function and the MySQL help entry for how to use the
>> command properly.  Is this the only types of documentation?  What
>> other types of documentation is required? Where do I look to create
>> the documentation above as well?  I tried to look through the
>> developer tutorials but found nothing on required documentation.
>> Please let me know.
>
> User-level documentation - for the manual, that is - shouldn't be
> difficult, the feature you've implemented is conceptually very easy to
> explain. And you don't need to do even that. We have a dedicated
> documentation team to write this for you, so all you *really* need to do
> is to explain the *feature* to them - and I think that the task
> description in worklog is good enough for that. If not - I'll handle
> that part, I'm not bound by a GSoC deadline :)
>
> Comments in the code, though, are all on you. I'll review your work - as
> a complete patch - this week, and tell you where more detailed comments
> are needed.
>
> Until that you can add more test cases (and fix bugs that will be
> discovered, if any :).
>
> Regards / Mit vielen Grüßen,
> Sergei
>
> --
>   __  ___     ___ ____  __
>  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik
> <serg@stripped>
>  / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
> /_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München
> 161028
>       <___/                
>  Sonnenallee 1, 85551 Kirchheim-Heimstetten
> Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
> Vorsitzender des Aufsichtsrates: Martin Häring
>
Thread
Fwd: GSoC Week 14 - August 2 - August 9| per query variable settingsJoseph Lukas10 Aug
  • Re: Fwd: GSoC Week 14 - August 2 - August 9 per query variable settingsSergei Golubchik10 Aug
    • Re: Fwd: GSoC Week 14 - August 2 - August 9 per query variable settingsJoseph Lukas10 Aug
      • Re: Fwd: GSoC Week 14 - August 2 - August 9 per query variable settingsSergei Golubchik11 Aug