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
