[Monetdb-developers] [Monetdb-checkins] clients/src/mapiclient MapiClient.mx, , 1.41, 1.42

Stefan Manegold Stefan.Manegold at cwi.nl
Wed Aug 15 14:48:12 CEST 2007


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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
> 
> 

-- 
| Dr. Stefan Manegold | mailto:Stefan.Manegold at 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       |




More information about the developers-list mailing list