Re: [Monetdb-developers] [Monetdb-checkins] clients/src/mapiclient MapiClient.mx, , 1.41, 1.42
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:
- the language being used has control for errors itself, e.g. SQL's auto-commit, or
- an error should not happen in batches, thus
- 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.
The feature will be dropped on the next commit
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:
- the language being used has control for errors itself, e.g. SQL's auto-commit, or
- an error should not happen in batches, thus
- 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
On 15-08-2007 14:48:12 +0200, Stefan Manegold wrote: ...
exit_on_error should not be necessary, if you assume the following:
- the language being used has control for errors itself, e.g. SQL's auto-commit, or
- an error should not happen in batches, thus
- 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.
On Wed, Aug 15, 2007 at 02:54:29PM +0200, Fabian Groffen wrote:
On 15-08-2007 14:48:12 +0200, Stefan Manegold wrote: ...
exit_on_error should not be necessary, if you assume the following:
- the language being used has control for errors itself, e.g. SQL's auto-commit, or
- an error should not happen in batches, thus
- 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.
I was refering to =================================================================== 2007/08/13 - mlkersten: clients/src/mapiclient/MapiClient.mx,1.24 With a better SQL rendering, we might as well use it as the default for stdin. All other use remains the same, so it does not affect the SQL testing output. =================================================================== which sounds like Martin implemented something.
I considered Martin's "According to Stefan this does not affect the test web." as refering to the lunch discussion we had about above 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?
Rendering has nothing to do with this, IMO.
Neither had my statement about effects of rendering changes (triggered by a checkin message that was talking about rendering changes, only; see above) anything to do with changing MapiClient commandline options and/or changing the behaviour of MapiClient in case of errors. Apparently not being phrased clearly/precisely enough, my orginal statement got mis-interpreted as "According to Stefan this(?) does not affect the test web.". I just tried to clearify this.
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.
Fine with me. So far, I haven't seen any request to do any changes to Mtest.py's use of MapiClient.
(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.
Right. And I answered also though I was not asked ;-)
Stefan
On 15-08-2007 15:23:56 +0200, Stefan Manegold wrote:
Martin didn't implement anything, he only threw away the exit_on_error thing, which is fine with me too.
I was refering to
2007/08/13 - mlkersten: clients/src/mapiclient/MapiClient.mx,1.24 With a better SQL rendering, we might as well use it as the default for stdin. All other use remains the same, so it does not affect the SQL testing output. =================================================================== which sounds like Martin implemented something.
I considered Martin's "According to Stefan this does not affect the test web." as refering to the lunch discussion we had about above checkin.
Ahh... I didn't play back those tapes yet.
(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.
Right. And I answered also though I was not asked ;-)
Uhm... right.
Conclusions: 1) "it" probably breaks 2) changes to Mtest are necessary 3) exit_on_error should not have been thrown away from the code 4) "commit at once" of Mtest and MapiClient code is preferred 5) as always: improve communication.
Removal of exit-on-error did not break the M5 tests.
The SQL tests show some differences related to rendering of dump_table and a few that require a little more study.
The situation in M4, AMDB, and XQuery is yet unknown.
Fabian Groffen wrote:
On 15-08-2007 15:23:56 +0200, Stefan Manegold wrote:
Martin didn't implement anything, he only threw away the exit_on_error thing, which is fine with me too.
I was refering to
2007/08/13 - mlkersten: clients/src/mapiclient/MapiClient.mx,1.24 With a better SQL rendering, we might as well use it as the default for stdin. All other use remains the same, so it does not affect the SQL testing output. =================================================================== which sounds like Martin implemented something.
I considered Martin's "According to Stefan this does not affect the test web." as refering to the lunch discussion we had about above checkin.
Ahh... I didn't play back those tapes yet.
(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.
Right. And I answered also though I was not asked ;-)
Uhm... right.
Conclusions:
- "it" probably breaks
- changes to Mtest are necessary
- exit_on_error should not have been thrown away from the code
- "commit at once" of Mtest and MapiClient code is preferred
- as always: improve communication.
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-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
participants (3)
-
Fabian Groffen -
Martin Kersten -
Stefan Manegold