On Wed, Aug 15, 2007 at 01:55:00PM +0200, Martin Kersten wrote:
Fabian Groffen wrote:
On 15-08-2007 11:24:47 +0000, Martin Kersten wrote:
- case 'e': + case 'E': echoquery = 1; continue; case 'f': @@ -1253,7 +1243,7 @@ setFormatter(s); continue; } - case 'x': + case 'e': exit_on_error = 1;
I suggest haveing -e for echo.
exit_on_error should not be necessary, if you assume the following: 1) the language being used has control for errors itself, e.g. SQL's auto-commit, or 2) an error should not happen in batches, thus 3) the client continues executing when reading from stdin, but dies on the first error when reading from file
Don't know how much this would affect testweb, but somewhere I feel it is only in an interactive session sensible to continue after an error. According to Stefan this does not affect the test web.
That's NOT what I said. I said: - changing the default SQL-rendering of MapiClient in case input is received via stdin (as opposed to from a file given on the commandline) did (apparenly) not affect testing, since Mtest.py runs SQL tests via `MapiClient -lsql TST.sql` and not via `MapiClient -lsql < TST.sql` (I derived this from running Mtest.py after Martin's respective checkin) In fact, this is NOT true: Also for SQL, like for MIL client and server tests, we give the tests file content via stdin to MapiClient and/or Mserver instead of providing the file ion the commandline, i.e., `MapiClient -lLANG < TST.EXT` `Mserver < TST.milS` instead of `MapiClient -lLANG TST.EXT < /dev/null` `Mserver TST.milS < /dev/null` We do this explicitly to keep tests running after the first error, as we want to be able to have tests that are supposed to trigger multiple errors, or to simply proceed after an error, instead of stopping immediately after the first error. Only for M5/MAL and XQuery, we give the test file on the commandline, i.e., `MapiClient -lxquery TST.xq < /dev/null` `mserver5 TST.mal < /dev/null` maily bacause the former (XQuery) did not support stdin initially, and the latter (M5) show(ed|s) significantly(?) different behavious between `mserver5 TST.mal < /dev/null` and `mserver5 < TST.mal` Hence, (1) I'm actually not sure, why changing the default SQL-rendering of MapiClient in case input is receivedvia stdin did/does not affect SQL testing --- possibly, because receiving input redirected from a file is (still) different from an interactive session, and only the latter has been modified? (2) Changes in the currect behaviour reagarding the treatment of errors can well affect testing! (3) The actual results of running testing (Mtest.py) is the *only* indication whether and how any code changes affect testing. Hence, simply run Mtest.py, and you'll know. That's *excatly* what testing and Mtest.py have been designed and implemented for, and what the are supposed to be used for. Stefan
The feature will be dropped on the next commit
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-checkins mailing list Monetdb-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |