Derby
  1. Derby
  2. DERBY-1776

ERROR 42Z72: XML syntax error; missing keyword(s): 'AS'. - Misleading text

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6, 10.3.1.4
    • Fix Version/s: 10.2.1.6, 10.3.1.4
    • Component/s: SQL
    • Labels:
      None

      Description

      create table t (i int, x xml);
      select xmlserialize from t;

      ERROR 42Z72: XML syntax error; missing keyword(s): 'AS'.

      This is not an 'XML Syntax error', it's a syntax in the SQL language. No need to have a special error messgae here, wouldn't the error be caught by regular parsing?

      1. d1776_v1.patch
        7 kB
        A B
      2. d1776_reuseInt.patch
        1 kB
        A B

        Activity

        Hide
        A B added a comment -

        > wouldn't the error be caught by regular parsing?

        Yes, regular parsing would catch this and other SQL/XML-related syntax errors, but the error message is somewhat unhelpful--I can't remember exactly, but it's something like

        "Encountered ')' at line x column y."

        And while it's true that a user could eventually figure it out, I thought that, given the high number of required keywords for the SQL/XML operators, it'd be more user friendly to actually provide a hint as to what was really missing. When you consider that the SQL/XML syntax tends to be rather wordy and that SQL/XML operators are often used one on top of the other (ex. XMLSERIALIZE (XMLQUERY(...)...), it's pretty easy to end up with long lines of query--and frankly, I as a user found myself getting impatient trying to figure out which operator was missing what keyword. So I created 42Z72.

        I guess one option is to remove that message altogether and let the user count lines and columns to find out where the unexpected ')' is and what it's supposed to be. But instead of that, I'd rather just reword the error message to address the fact that this is "not an XML syntax error, it's a syntax in the SQL language". Maybe something like:

        ERROR 42Z72: Missing SQL/XML keyword(s): 'AS'.

        Does that seem like an acceptable approach?

        Show
        A B added a comment - > wouldn't the error be caught by regular parsing? Yes, regular parsing would catch this and other SQL/XML-related syntax errors, but the error message is somewhat unhelpful--I can't remember exactly, but it's something like "Encountered ')' at line x column y." And while it's true that a user could eventually figure it out, I thought that, given the high number of required keywords for the SQL/XML operators, it'd be more user friendly to actually provide a hint as to what was really missing. When you consider that the SQL/XML syntax tends to be rather wordy and that SQL/XML operators are often used one on top of the other (ex. XMLSERIALIZE (XMLQUERY(...)...), it's pretty easy to end up with long lines of query--and frankly, I as a user found myself getting impatient trying to figure out which operator was missing what keyword. So I created 42Z72. I guess one option is to remove that message altogether and let the user count lines and columns to find out where the unexpected ')' is and what it's supposed to be. But instead of that, I'd rather just reword the error message to address the fact that this is "not an XML syntax error, it's a syntax in the SQL language". Maybe something like: ERROR 42Z72: Missing SQL/XML keyword(s): 'AS'. Does that seem like an acceptable approach?
        Hide
        Daniel John Debrunner added a comment -

        Yes, though the loss of the line and column number is a shame.
        Be useful to know how you implemented this, so that other more helpful messages could be added in the future.
        Maybe add to the wiki?
        http://wiki.apache.org/db-derby/LanguageSystem

        Show
        Daniel John Debrunner added a comment - Yes, though the loss of the line and column number is a shame. Be useful to know how you implemented this, so that other more helpful messages could be added in the future. Maybe add to the wiki? http://wiki.apache.org/db-derby/LanguageSystem
        Hide
        A B added a comment -

        Well, after that paragraph of justification, it turns out that there are only three places where we use the 42Z79 SQLSTATE. But still, I think it's a useful error message and should be kept around; it could come in handy further down the road if SQL/XML functionality is expanded.

        As for line/column numbers, it turns out that those values are readily available from within sqlgrammar.jj and thus can easily be passed as part of the error message. The only potential downside that I can see is that we have to create an Integer object out of the line/col numbers in order to pass them to the StandardException constructor...but maybe that's not a big deal...? The fact that no one has done this earlier makes me wonder if there's some "gotcha" here that I'm missing, but I haven't seen any problems with it just yet...

        Attaching a patch d1776_v1.patch that changes the error message for 42Z79 as mentioned in my previous comment and also does the following:

        1. Adds line and column numbers to the error message to indicate where
        the missing keyword is expected.

        2. Removes one "lookahead" call that was causing 42Z79 to be raised
        for a missing "AS" keyword when in fact the keyword was present
        (what was missing was the datatype). To avoid confusion, I
        removed the lookahead and now the user will see a more generic
        42X01 error in that particular case.

        3. Updated xml_general master files accordingly.

        So with this patch applied, instead of:

        select xmlserialize from t;
        ERROR 42Z72: XML syntax error; missing keyword(s): 'AS'.

        we'll now see:

        create table t (i int, x xml);
        ERROR 42Z72: Missing SQL/XML keyword(s) 'AS' at line 1, column 22.

        I ran xmlSuite with this patch and all of the tests passed. I haven't run derbyall yet and I don't expect any failures (since the changes are theoretically limited to XML) but I will try to run it tonight just for sanity. In the meantime, review comments would be great.

        Show
        A B added a comment - Well, after that paragraph of justification, it turns out that there are only three places where we use the 42Z79 SQLSTATE. But still, I think it's a useful error message and should be kept around; it could come in handy further down the road if SQL/XML functionality is expanded. As for line/column numbers, it turns out that those values are readily available from within sqlgrammar.jj and thus can easily be passed as part of the error message. The only potential downside that I can see is that we have to create an Integer object out of the line/col numbers in order to pass them to the StandardException constructor...but maybe that's not a big deal...? The fact that no one has done this earlier makes me wonder if there's some "gotcha" here that I'm missing, but I haven't seen any problems with it just yet... Attaching a patch d1776_v1.patch that changes the error message for 42Z79 as mentioned in my previous comment and also does the following: 1. Adds line and column numbers to the error message to indicate where the missing keyword is expected. 2. Removes one "lookahead" call that was causing 42Z79 to be raised for a missing "AS" keyword when in fact the keyword was present (what was missing was the datatype). To avoid confusion, I removed the lookahead and now the user will see a more generic 42X01 error in that particular case. 3. Updated xml_general master files accordingly. So with this patch applied, instead of: select xmlserialize from t; ERROR 42Z72: XML syntax error; missing keyword(s): 'AS'. we'll now see: create table t (i int, x xml); ERROR 42Z72: Missing SQL/XML keyword(s) 'AS' at line 1, column 22. I ran xmlSuite with this patch and all of the tests passed. I haven't run derbyall yet and I don't expect any failures (since the changes are theoretically limited to XML) but I will try to run it tonight just for sanity. In the meantime, review comments would be great.
        Hide
        A B added a comment -

        derbyall on Windows 2000 with ibm142 against sane jars ran with no new failures. So this patch is ready for review/commit.

        Show
        A B added a comment - derbyall on Windows 2000 with ibm142 against sane jars ran with no new failures. So this patch is ready for review/commit.
        Hide
        Mike Matrigali added a comment -

        reviewed and committed patch as is to trunk. It can be merged to 10.2.

        Well, after that paragraph of justification, it turns out that there are only three places where we use the 42Z79 SQLSTATE. But still, I think it's a useful error message and should be kept around; it could come in handy further down the road if SQL/XML functionality is expanded.

        As for line/column numbers, it turns out that those values are readily available from within sqlgrammar.jj and thus can easily be passed as part of the error message. The only potential downside that I can see is that we have to create an Integer object out of the line/col numbers in order to pass them to the StandardException constructor...but maybe that's not a big deal...? The fact that no one has done this earlier makes me wonder if there's some "gotcha" here that I'm missing, but I haven't seen any problems with it just yet...

        Attaching a patch d1776_v1.patch that changes the error message for 42Z79 as mentioned in my previous comment and also does the following:

        1. Adds line and column numbers to the error message to indicate where
        the missing keyword is expected.

        2. Removes one "lookahead" call that was causing 42Z79 to be raised
        for a missing "AS" keyword when in fact the keyword was present
        (what was missing was the datatype). To avoid confusion, I
        removed the lookahead and now the user will see a more generic
        42X01 error in that particular case.

        3. Updated xml_general master files accordingly.

        So with this patch applied, instead of:

        select xmlserialize from t;
        ERROR 42Z72: XML syntax error; missing keyword(s): 'AS'.

        we'll now see:

        create table t (i int, x xml);
        ERROR 42Z72: Missing SQL/XML keyword(s) 'AS' at line 1, column 22.

        Show
        Mike Matrigali added a comment - reviewed and committed patch as is to trunk. It can be merged to 10.2. Well, after that paragraph of justification, it turns out that there are only three places where we use the 42Z79 SQLSTATE. But still, I think it's a useful error message and should be kept around; it could come in handy further down the road if SQL/XML functionality is expanded. As for line/column numbers, it turns out that those values are readily available from within sqlgrammar.jj and thus can easily be passed as part of the error message. The only potential downside that I can see is that we have to create an Integer object out of the line/col numbers in order to pass them to the StandardException constructor...but maybe that's not a big deal...? The fact that no one has done this earlier makes me wonder if there's some "gotcha" here that I'm missing, but I haven't seen any problems with it just yet... Attaching a patch d1776_v1.patch that changes the error message for 42Z79 as mentioned in my previous comment and also does the following: 1. Adds line and column numbers to the error message to indicate where the missing keyword is expected. 2. Removes one "lookahead" call that was causing 42Z79 to be raised for a missing "AS" keyword when in fact the keyword was present (what was missing was the datatype). To avoid confusion, I removed the lookahead and now the user will see a more generic 42X01 error in that particular case. 3. Updated xml_general master files accordingly. So with this patch applied, instead of: select xmlserialize from t; ERROR 42Z72: XML syntax error; missing keyword(s): 'AS'. we'll now see: create table t (i int, x xml); ERROR 42Z72: Missing SQL/XML keyword(s) 'AS' at line 1, column 22.
        Hide
        A B added a comment -

        In a review comment for a different issue someone mentioned that instead of creating new Integer() objects it'd be better to use the Derby ReuseFactory where possible to avoid excessive object creation. I get the feeling that's not a big deal with the _v1 patch for this issue, but I nonetheless thought it'd be a good idea to follow that advice with the changes.

        So I'm attaching a tiny patch, d1776_reuseInt.patch, that replaces the calls to "new Integer()" in the _v1 patch (which has already been committed) with calls to ReuseFactory.getInteger(). Functionally, the patch doesn't change anything.

        I ran xmlSuite on Windows 2000 with ibm142 and all tests passed.

        Show
        A B added a comment - In a review comment for a different issue someone mentioned that instead of creating new Integer() objects it'd be better to use the Derby ReuseFactory where possible to avoid excessive object creation. I get the feeling that's not a big deal with the _v1 patch for this issue, but I nonetheless thought it'd be a good idea to follow that advice with the changes. So I'm attaching a tiny patch, d1776_reuseInt.patch, that replaces the calls to "new Integer()" in the _v1 patch (which has already been committed) with calls to ReuseFactory.getInteger(). Functionally, the patch doesn't change anything. I ran xmlSuite on Windows 2000 with ibm142 and all tests passed.
        Hide
        Andrew McIntyre added a comment -

        Marking resolved, merged to 10.2 branch with revision 449013.

        Show
        Andrew McIntyre added a comment - Marking resolved, merged to 10.2 branch with revision 449013.
        Hide
        A B added a comment -

        Changes in trunk and 10.2 and no further comments, so closing the issue.

        Show
        A B added a comment - Changes in trunk and 10.2 and no further comments, so closing the issue.

          People

          • Assignee:
            A B
            Reporter:
            Daniel John Debrunner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development