[Monetdb-developers] MXQ: MapiClient -lxquery output mode
Hi all, As you may have noticed by now, MapiClient has been changed to act differently for xquery than it used to before. I reverted the original behaviour for greener XQuery pastures, but the change itself is not done without any doubts from my side. MapiClient used to report errors in xquery mode in a terse way; it just reported the error message, without the leading bang (!). For all other languages, MapiClient is more verbose: it prints the query being executed, action taken and the error with leading bangs prefixed with "ERROR: ". Niels made xquery behave as all the other languages for errors for the sake of consistency; a thing I wholeheartedly agree with. However, some considerable amount of tests in the XQuery testweb has to be reapproved if this change is put through, which was not done at the same time of Niels' change. So far for the history. Since I'd like to have consistency (agreeing with Niels), I'd like to see MapiClient reporting errors for xquery in the verbose way like it does for all other languages. However, why was this special mode enabled for xquery in the first place? My best guess is that because XQuery is non-interactive (through MapiClient) it makes no sense to print the query upon error, because the query already is in a file, and it can only contain one, unlike SQL, where it is nice to know *which* statement was being executed. Or did somebody just not like MapiClient's error output? I for one like the more terse error output in a way, and would be in favour of adding a flag to enable this error reporting. Here, I'd like to open up the discussion for who thinks that is necessary. I go for removing the special error output for xquery and approving all tests in XQuery testweb that are affected by that change. With no (negative) response to this message, I will assume this change is ok with the XQuery people and "implement" this change somewhere next week.
Hi Fabian, I support the request for consistency and verboseness. The original reasons for the MAPI text exchange protocol (which dates back to the early 80's ;-)) was to simplify analysis of responses received from a server by any client tool. Including simple shell script filters. That's the reason for #, [, and !ERROR, !FATAL, !WARNING in all output lines. To be consistent with this policy, xquery could have introduced its own leader character(s) to analyse the result, and which could be stripped (restyled) by any front-end easily. Aside from the verbose information on the origin of an error and context, I would not be pleased if an error message appeared hidden at an arbitrary place in a 100MB XML output. But, of course, the XQuery standardization committee may have more wisdom or vision on how to deal with error responses. regards, Martin ps. Thanks in advance if you take the burden to approve them by hand. Watch out for RSI ! Fabian Groffen wrote:
Hi all,
As you may have noticed by now, MapiClient has been changed to act differently for xquery than it used to before. I reverted the original behaviour for greener XQuery pastures, but the change itself is not done without any doubts from my side.
MapiClient used to report errors in xquery mode in a terse way; it just reported the error message, without the leading bang (!). For all other languages, MapiClient is more verbose: it prints the query being executed, action taken and the error with leading bangs prefixed with "ERROR: ". Niels made xquery behave as all the other languages for errors for the sake of consistency; a thing I wholeheartedly agree with. However, some considerable amount of tests in the XQuery testweb has to be reapproved if this change is put through, which was not done at the same time of Niels' change.
So far for the history. Since I'd like to have consistency (agreeing with Niels), I'd like to see MapiClient reporting errors for xquery in the verbose way like it does for all other languages. However, why was this special mode enabled for xquery in the first place? My best guess is that because XQuery is non-interactive (through MapiClient) it makes no sense to print the query upon error, because the query already is in a file, and it can only contain one, unlike SQL, where it is nice to know *which* statement was being executed. Or did somebody just not like MapiClient's error output?
I for one like the more terse error output in a way, and would be in favour of adding a flag to enable this error reporting.
Here, I'd like to open up the discussion for who thinks that is necessary. I go for removing the special error output for xquery and approving all tests in XQuery testweb that are affected by that change. With no (negative) response to this message, I will assume this change is ok with the XQuery people and "implement" this change somewhere next week.
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
Dear all, I have no strong opinion about how error messages shoud look like in MonetDB/XQuery (though I slightly fancy the idea of having consistent solutions and "only one way to do the same thing" all over the place), hence, any solution is fine with me as long as - all changes are motivated and documented properly (thus, even in a year's time, we can still (conveniently and efficiently) retrieve who did what and why) - all changes comply with any standards that do apply (if any) - ALL checkins are (1) ATOMIC and (2) CONSISTENT, i.e., (1) all modification that make up a (larger) change are check-in in ONE go, together with the respective desired/intented changes of the expected/stable output of tests, thus (2) an Mtest-run (on the very developer's favorite platform) after the changes shows the same result as before the changes --- obviously, checking this is trivial (only) if the Mtest-run was all-green before the changes... (Obviously, changes that result in a less red (more green) Mtest-run are "acceptable"; changes that result in a less green (more red) Mtest-run are *forbidden*.) Stefan On Thu, Aug 17, 2006 at 10:38:22PM +0200, Martin Kersten wrote:
Hi Fabian,
I support the request for consistency and verboseness. The original reasons for the MAPI text exchange protocol (which dates back to the early 80's ;-)) was to simplify analysis of responses received from a server by any client tool. Including simple shell script filters. That's the reason for #, [, and !ERROR, !FATAL, !WARNING in all output lines. To be consistent with this policy, xquery could have introduced its own leader character(s) to analyse the result, and which could be stripped (restyled) by any front-end easily.
Aside from the verbose information on the origin of an error and context, I would not be pleased if an error message appeared hidden at an arbitrary place in a 100MB XML output. But, of course, the XQuery standardization committee may have more wisdom or vision on how to deal with error responses.
regards, Martin ps. Thanks in advance if you take the burden to approve them by hand. Watch out for RSI !
ps: To save him from RSI, I can help (also) Fabian with the approving...
Fabian Groffen wrote:
Hi all,
As you may have noticed by now, MapiClient has been changed to act differently for xquery than it used to before. I reverted the original behaviour for greener XQuery pastures, but the change itself is not done without any doubts from my side.
MapiClient used to report errors in xquery mode in a terse way; it just reported the error message, without the leading bang (!). For all other languages, MapiClient is more verbose: it prints the query being executed, action taken and the error with leading bangs prefixed with "ERROR: ". Niels made xquery behave as all the other languages for errors for the sake of consistency; a thing I wholeheartedly agree with. However, some considerable amount of tests in the XQuery testweb has to be reapproved if this change is put through, which was not done at the same time of Niels' change.
So far for the history. Since I'd like to have consistency (agreeing with Niels), I'd like to see MapiClient reporting errors for xquery in the verbose way like it does for all other languages. However, why was this special mode enabled for xquery in the first place? My best guess is that because XQuery is non-interactive (through MapiClient) it makes no sense to print the query upon error, because the query already is in a file, and it can only contain one, unlike SQL, where it is nice to know *which* statement was being executed. Or did somebody just not like MapiClient's error output?
I for one like the more terse error output in a way, and would be in favour of adding a flag to enable this error reporting.
Here, I'd like to open up the discussion for who thinks that is necessary. I go for removing the special error output for xquery and approving all tests in XQuery testweb that are affected by that change. With no (negative) response to this message, I will assume this change is ok with the XQuery people and "implement" this change somewhere next week.
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- | 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 |
participants (3)
-
Fabian Groffen -
Martin Kersten -
Stefan Manegold