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

Fabian Groffen Fabian.Groffen at cwi.nl
Wed Aug 15 14:54:29 CEST 2007


On 15-08-2007 14:48:12 +0200, Stefan Manegold wrote:
...
> > > 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)

Martin didn't implement anything, he only threw away the exit_on_error
thing, which is fine with me too.

> 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?

Rendering has nothing to do with this, IMO.  It's about quiting after
the first error encountered or not.  Anyway, I think testweb should just
pass --raw or something to MapiClient when using it, to obtain the raw
protocol view that was normal before Martin started working on this.

> (2) Changes in the currect behaviour reagarding the treatment of errors can
>     well affect testing!

That was what I was wondering, with regard to my suggested scheme.

> (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.

Sometimes asking someone is much faster than implementing the code, and
running Mtest.





More information about the developers-list mailing list