Derby
  1. Derby
  2. DERBY-2785

ij "describe" built in command cannot describe a table named "run"

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.2.2.0
    • Fix Version/s: 10.7.1.1
    • Component/s: Tools
    • Labels:
      None
    • Environment:
      OS-X, Java 1.5
    • Urgency:
      Normal
    • Issue & fix info:
      Newcomer, Repro attached

      Description

      steps to duplicate:

      (attach ij to any database)

      ij> create table run (i int);
      0 rows inserted/updated/deleted
      ij> desc run;
      ERROR 42X01: Syntax error: Encountered "desc" at line 1, column 1.
      ij>

      I think this is a parser problem within ij where the "run" is taken as a token and that token is not included in the definition of a tablename expression in the grammer (should be an easy fix).

      1. test.out
        2 kB
        Eranda Sooriyabandara
      2. step logs.txt
        10 kB
        Eranda Sooriyabandara
      3. junitAll.out
        16 kB
        Eranda Sooriyabandara
      4. junitAll.out
        16 kB
        Eranda Sooriyabandara
      5. describeKeywords.diff
        0.7 kB
        Bryan Pendleton
      6. derbyall_report.txt
        14 kB
        Eranda Sooriyabandara
      7. derbyall_report.txt
        3 kB
        Eranda Sooriyabandara
      8. Derby-2785.diff
        0.8 kB
        Eranda Sooriyabandara
      9. derby-2785.diff
        0.8 kB
        Eranda Sooriyabandara
      10. derby-2785.diff
        1 kB
        Eranda Sooriyabandara
      11. derby-2785.diff
        1 kB
        Eranda Sooriyabandara
      12. derby.log
        6 kB
        Eranda Sooriyabandara
      13. caidentifier.diff
        0.8 kB
        Bryan Pendleton
      14. caidentifier.diff
        0.8 kB
        Eranda Sooriyabandara
      15. caidentifier.diff
        1 kB
        Eranda Sooriyabandara
      16. caidentifier.diff
        3 kB
        Eranda Sooriyabandara

        Activity

        Hide
        Eranda Sooriyabandara added a comment -

        Thanks Bryan for committing and thanks all for the suggestions.
        I am closing this issue.

        Show
        Eranda Sooriyabandara added a comment - Thanks Bryan for committing and thanks all for the suggestions. I am closing this issue.
        Hide
        Bryan Pendleton added a comment -

        I think this patch is solid, and have committed it to the trunk as
        revision 958431. Thanks Eranda for all the hard work on the patch,
        and thanks Sylvain and others for suggestions and reviews along the way.

        Show
        Bryan Pendleton added a comment - I think this patch is solid, and have committed it to the trunk as revision 958431. Thanks Eranda for all the hard work on the patch, and thanks Sylvain and others for suggestions and reviews along the way.
        Hide
        Bryan Pendleton added a comment -

        I will have a close look at your latest patch soon. Thanks for adding the tests!

        Show
        Bryan Pendleton added a comment - I will have a close look at your latest patch soon. Thanks for adding the tests!
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        All problem solved.
        Here I included two tests to verify that this works.Also here I am attaching the patch for your review.
        Thanks

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, All problem solved. Here I included two tests to verify that this works.Also here I am attaching the patch for your review. Thanks
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        Now that thing was solved and I added some test to the ij7. But it gave me the following exception.

        ij7(org.apache.derbyTesting.functionTests.tests.tools.ToolScripts)junit.framework.ComparisonFailure: Output at line 113 expected:<[ij> DESCRIBE APP.t1;]> but was:<[org.apache.derby.impl.tools.ij.ijException: No table exists with the name T1]>
        at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:106)
        at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:198)
        at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
        at junit.extensions.TestSetup.run(TestSetup.java:27)
        at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
        at org.apache.derbyTesting.functionTests.tests.tools.ToolScripts.main(ToolScripts.java:101)

        FAILURES!!!
        Tests run: 1, Failures: 1, Errors: 0

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, Now that thing was solved and I added some test to the ij7. But it gave me the following exception. ij7(org.apache.derbyTesting.functionTests.tests.tools.ToolScripts)junit.framework.ComparisonFailure: Output at line 113 expected:< [ij> DESCRIBE APP.t1;] > but was:< [org.apache.derby.impl.tools.ij.ijException: No table exists with the name T1] > at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:106) at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:198) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at org.apache.derbyTesting.functionTests.tests.tools.ToolScripts.main(ToolScripts.java:101) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        I tried to work with new repo and get the following error
        ij> describe run;
        JAVA ERROR: java.lang.Error: Missing return statement in function
        java.lang.Error: Missing return statement in function
        at org.apache.derby.impl.tools.ij.ij.caIdentifier(ij.java:2640)
        at org.apache.derby.impl.tools.ij.ij.DescTableStatement(ij.java:1445)
        at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:1110)
        at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:341)
        at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:261)
        at org.apache.derby.impl.tools.ij.Main.go(Main.java:229)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184)
        at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
        at org.apache.derby.tools.ij.main(ij.java:59)

        I check ij.java and see as follows

        Token t=null;
        String i=null;
        if (jj_2_122(2))

        { i = keyword(); }

        else if (jj_2_123(2)) {
        t = jj_consume_token(IDENTIFIER);
        haveConnection();
        DatabaseMetaData dbmd = theConnection.getMetaData();
        String identifier = i;

        if(i==null)
        identifier = t.image;

        if (dbmd.storesLowerCaseIdentifiers())
        identifier = identifier.toLowerCase(Locale.ENGLISH);
        else if (dbmd.storesUpperCaseIdentifiers())
        identifier = identifier.toUpperCase(Locale.ENGLISH);

        {if (true) return identifier;}

        } else

        { jj_consume_token(-1); throw new ParseException(); }

        throw new Error("Missing return statement in function");

        According to the code when we give a key word as table the error should appear.
        Why this occurs suddenly? Here I am attaching the patch.
        thanks

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, I tried to work with new repo and get the following error ij> describe run; JAVA ERROR: java.lang.Error: Missing return statement in function java.lang.Error: Missing return statement in function at org.apache.derby.impl.tools.ij.ij.caIdentifier(ij.java:2640) at org.apache.derby.impl.tools.ij.ij.DescTableStatement(ij.java:1445) at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:1110) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:341) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:261) at org.apache.derby.impl.tools.ij.Main.go(Main.java:229) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184) at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) at org.apache.derby.tools.ij.main(ij.java:59) I check ij.java and see as follows Token t=null; String i=null; if (jj_2_122(2)) { i = keyword(); } else if (jj_2_123(2)) { t = jj_consume_token(IDENTIFIER); haveConnection(); DatabaseMetaData dbmd = theConnection.getMetaData(); String identifier = i; if(i==null) identifier = t.image; if (dbmd.storesLowerCaseIdentifiers()) identifier = identifier.toLowerCase(Locale.ENGLISH); else if (dbmd.storesUpperCaseIdentifiers()) identifier = identifier.toUpperCase(Locale.ENGLISH); {if (true) return identifier;} } else { jj_consume_token(-1); throw new ParseException(); } throw new Error("Missing return statement in function"); According to the code when we give a key word as table the error should appear. Why this occurs suddenly? Here I am attaching the patch. thanks
        Hide
        Bryan Pendleton added a comment -

        I think the new tests could be added to
        ./java/testing/org/apache/derbyTesting/functionTests/tests/tools/ij7.sql

        The ij7.sql test runs as part of the complete JUnit test suite, and you
        can also run just that test by itself by doing:
        java org.apache.derbyTesting.functionTests.tests.tools.ToolScripts ij7
        with your classpath set up like it would be to run the complete suite.

        Show
        Bryan Pendleton added a comment - I think the new tests could be added to ./java/testing/org/apache/derbyTesting/functionTests/tests/tools/ij7.sql The ij7.sql test runs as part of the complete JUnit test suite, and you can also run just that test by itself by doing: java org.apache.derbyTesting.functionTests.tests.tools.ToolScripts ij7 with your classpath set up like it would be to run the complete suite.
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        Where can I put the test? I could not able to find the place where the "describe" test?

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, Where can I put the test? I could not able to find the place where the "describe" test?
        Hide
        Bryan Pendleton added a comment -

        Are there new tests to be added as part of this patch? I am looking at caidentifier.diff,
        is that the right patch to look at? I think we need to add some tests which demonstrate
        the behavior of IJ when using some of the new features, such as 'describe "run"', etc.

        Show
        Bryan Pendleton added a comment - Are there new tests to be added as part of this patch? I am looking at caidentifier.diff, is that the right patch to look at? I think we need to add some tests which demonstrate the behavior of IJ when using some of the new features, such as 'describe "run"', etc.
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        My trunk was not updated for a week and there were some updates I in BootLockTest. After updating trunk it successfully ran. Also I did the test again and all JUnit tests were passed. I think you may commit the patch now.
        Thanks
        PS: Thanks Knut, it will be very useful when tracking

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, My trunk was not updated for a week and there were some updates I in BootLockTest. After updating trunk it successfully ran. Also I did the test again and all JUnit tests were passed. I think you may commit the patch now. Thanks PS: Thanks Knut, it will be very useful when tracking
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda, I wonder if you are seeing DERBY-4667?

        Show
        Bryan Pendleton added a comment - Hi Eranda, I wonder if you are seeing DERBY-4667 ?
        Hide
        Knut Anders Hatlen added a comment -

        I see you've already solved the NPE in ij, but I thought I'd mention the ij.exceptionTrace property in case you need to debug similar problems later. The property makes ij print the stack trace when it encounters an exception: http://db.apache.org/derby/docs/dev/tools/rtoolsijproprefexceptiontrace.html

        Show
        Knut Anders Hatlen added a comment - I see you've already solved the NPE in ij, but I thought I'd mention the ij.exceptionTrace property in case you need to debug similar problems later. The property makes ij print the stack trace when it encounters an exception: http://db.apache.org/derby/docs/dev/tools/rtoolsijproprefexceptiontrace.html
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        Yes it does.
        Here I am attaching the log file with this and the test output file with this.
        thanks

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, Yes it does. Here I am attaching the log file with this and the test output file with this. thanks
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda,
        It looks like your most recent diff has resolved the NPE problems in ij7. Great!

        Now we just have to figure out what is wrong with your NetworkServer setup
        in your environment, that is causing those three NetworkServer test failures.

        What happens if you do:

        java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.store.BootLockTest

        Does that reproduce the problem in your environment?

        Show
        Bryan Pendleton added a comment - Hi Eranda, It looks like your most recent diff has resolved the NPE problems in ij7. Great! Now we just have to figure out what is wrong with your NetworkServer setup in your environment, that is causing those three NetworkServer test failures. What happens if you do: java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.store.BootLockTest Does that reproduce the problem in your environment?
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        Got the results of the tests and I don't see any difference between derbyall tests. But in the JUnit tests again there were 3 exceptions, one is same as in the previous and two new exceptions. Are there any method to reproduce them.
        Thanks
        Eranda

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, Got the results of the tests and I don't see any difference between derbyall tests. But in the JUnit tests again there were 3 exceptions, one is same as in the previous and two new exceptions. Are there any method to reproduce them. Thanks Eranda
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        Got the point,
        [ i=keyword()|t=<IDENTIFIER> ] means it is optional. Though both i and t doesn't have a match, execution proceed to the block. I remove squire brackets and now it passes my basic tests.
        Here I am attaching the updated patch and I will attach derby all and JUnit test results asap.
        Thanks
        Eranda

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, Got the point, [ i=keyword()|t=<IDENTIFIER> ] means it is optional. Though both i and t doesn't have a match, execution proceed to the block. I remove squire brackets and now it passes my basic tests. Here I am attaching the updated patch and I will attach derby all and JUnit test results asap. Thanks Eranda
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda,

        I see you are right, there is no exception in the derby.log.

        To see the stack trace, I had to add

        e.printStackTrace() ;

        to the 2 catch() blocks near line 375 of
        java/tools/org/apache/derby/impl/tools/ij/utilMain.java

        When I did that, I see:

        ij> describe 'CamelCaseTable';
        java.lang.NullPointerException
        at org.apache.derby.impl.tools.ij.ij.caIdentifier(ij.java:2635)
        at org.apache.derby.impl.tools.ij.ij.DescTableStatement(ij.java:1445)
        at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:1110)
        at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:341)
        at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:261)
        at org.apache.derby.impl.tools.ij.Main.go(Main.java:229)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184)
        at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
        at org.apache.derby.tools.ij.main(ij.java:59)
        JAVA ERROR: java.lang.NullPointerException

        In my tree, line 2635 of ij.java is the line:

        haveConnection();
        DatabaseMetaData dbmd = theConnection.getMetaData();
        String identifier = i;

        if(t!=null)
        identifier = t.image;
        if (dbmd.storesLowerCaseIdentifiers())
        identifier = identifier.toLowerCase(Locale.ENGLISH);
        else if (dbmd.storesUpperCaseIdentifiers())
        identifier = identifier.toUpperCase(Locale.ENGLISH); <====== THIS IS LINE 2635

        {if (true) return identifier;}

        throw new Error("Missing return statement in function");
        }

        So 'identifier' must be NULL at this point.

        Maybe you can investigate and determine why this is?

        thanks,

        bryan

        Show
        Bryan Pendleton added a comment - Hi Eranda, I see you are right, there is no exception in the derby.log. To see the stack trace, I had to add e.printStackTrace() ; to the 2 catch() blocks near line 375 of java/tools/org/apache/derby/impl/tools/ij/utilMain.java When I did that, I see: ij> describe 'CamelCaseTable'; java.lang.NullPointerException at org.apache.derby.impl.tools.ij.ij.caIdentifier(ij.java:2635) at org.apache.derby.impl.tools.ij.ij.DescTableStatement(ij.java:1445) at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:1110) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:341) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:261) at org.apache.derby.impl.tools.ij.Main.go(Main.java:229) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184) at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) at org.apache.derby.tools.ij.main(ij.java:59) JAVA ERROR: java.lang.NullPointerException In my tree, line 2635 of ij.java is the line: haveConnection(); DatabaseMetaData dbmd = theConnection.getMetaData(); String identifier = i; if(t!=null) identifier = t.image; if (dbmd.storesLowerCaseIdentifiers()) identifier = identifier.toLowerCase(Locale.ENGLISH); else if (dbmd.storesUpperCaseIdentifiers()) identifier = identifier.toUpperCase(Locale.ENGLISH); <====== THIS IS LINE 2635 {if (true) return identifier;} throw new Error("Missing return statement in function"); } So 'identifier' must be NULL at this point. Maybe you can investigate and determine why this is? thanks, bryan
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        I did it but in the log I don't see the stack trace of the errors.
        Here is my log
        ----------------------------------------------------------------
        2010-06-20 05:28:27.059 GMT:
        Booting Derby version The Apache Software Foundation - Apache Derby - 10.7.0.0 alpha - (1): instance a816c00e-0129-53d4-4411-000001c4b128
        on database directory /home/eranda/Desktop/derby/trunk/test2/brydb with class loader sun.misc.Launcher$AppClassLoader@1ea2dfe

        Database Class Loader started - derby.database.classpath=''

        2010-06-20 05:34:20.494 GMT:
        Shutting down instance a816c00e-0129-53d4-4411-000001c4b128 with class loader sun.misc.Launcher$AppClassLoader@1ea2dfe
        ----------------------------------------------------------------
        thanks
        Eranda

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, I did it but in the log I don't see the stack trace of the errors. Here is my log ---------------------------------------------------------------- 2010-06-20 05:28:27.059 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.7.0.0 alpha - (1): instance a816c00e-0129-53d4-4411-000001c4b128 on database directory /home/eranda/Desktop/derby/trunk/test2/brydb with class loader sun.misc.Launcher$AppClassLoader@1ea2dfe Database Class Loader started - derby.database.classpath='' 2010-06-20 05:34:20.494 GMT: Shutting down instance a816c00e-0129-53d4-4411-000001c4b128 with class loader sun.misc.Launcher$AppClassLoader@1ea2dfe ---------------------------------------------------------------- thanks Eranda
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda

        You could try running one of those queries interactively, and then look
        in your derby.log file for the stack trace information:

        java org.apache.derby.tools.ij

        connect 'jdbc:derby:brydb;create=true';
        describe 'CamelCaseTable';
        quit;

        After you run this, you should have a 'derby.log' in your current directory.

        thanks,

        bryan

        Show
        Bryan Pendleton added a comment - Hi Eranda You could try running one of those queries interactively, and then look in your derby.log file for the stack trace information: java org.apache.derby.tools.ij connect 'jdbc:derby:brydb;create=true'; describe 'CamelCaseTable'; quit; After you run this, you should have a 'derby.log' in your current directory. thanks, bryan
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        Here I found that this exception occurs with the presence of the single quotations with table name

        ij> DESCRIBE APP.t1;
        COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL&
        ------------------------------------------------------------------------------
        I |INTEGER |0 |10 |10 |AUTOINCRE&|NULL |NO
        D |DECIMAL |2 |10 |5 |NULL |NULL |YES
        TEST |VARCHAR |NULL|NULL|20 |NULL |40 |YES
        ij> DESCRIBE app.t1;
        COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL&
        ------------------------------------------------------------------------------
        I |INTEGER |0 |10 |10 |AUTOINCRE&|NULL |NO
        D |DECIMAL |2 |10 |5 |NULL |NULL |YES
        TEST |VARCHAR |NULL|NULL|20 |NULL |40 |YES
        ij> DESCRIBE v1;
        COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL&
        ------------------------------------------------------------------------------
        I |INTEGER |0 |10 |10 |NULL |NULL |NO
        D |DECIMAL |2 |10 |5 |NULL |NULL |YES
        TEST |VARCHAR |NULL|NULL|20 |NULL |40 |YES

        ij> – should find the table, as quoted string case is preserved.
        describe 'CamelCaseTable';
        JAVA ERROR: java.lang.NullPointerException
        ij> – should fail, as case is wrong:
        describe 'CAMELCaseTable';
        JAVA ERROR: java.lang.NullPointerException
        ij> – should work, note that schema name must be upper case:
        describe 'APP.CamelCaseTable';
        JAVA ERROR: java.lang.NullPointerException
        ij> set SCHEMA USER1;
        0 rows inserted/updated/deleted
        ij> – should work, even after changing default schema, so long as schema is right
        describe 'APP.CamelCaseTable';
        JAVA ERROR: java.lang.NullPointerException
        ij> – should fail, since table is in the other schema
        describe 'CamelCaseTable';
        JAVA ERROR: java.lang.NullPointerException
        ij> – Can use * as a wildcard for table name:
        describe '*';
        JAVA ERROR: java.lang.NullPointerException
        ij> describe 'APP.*';
        JAVA ERROR: java.lang.NullPointerException
        ij> – Observe behavior with empty string:
        describe '';
        JAVA ERROR: java.lang.NullPointerException
        ij>

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, Here I found that this exception occurs with the presence of the single quotations with table name ij> DESCRIBE APP.t1; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ I |INTEGER |0 |10 |10 |AUTOINCRE&|NULL |NO D |DECIMAL |2 |10 |5 |NULL |NULL |YES TEST |VARCHAR |NULL|NULL|20 |NULL |40 |YES ij> DESCRIBE app.t1; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ I |INTEGER |0 |10 |10 |AUTOINCRE&|NULL |NO D |DECIMAL |2 |10 |5 |NULL |NULL |YES TEST |VARCHAR |NULL|NULL|20 |NULL |40 |YES ij> DESCRIBE v1; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ I |INTEGER |0 |10 |10 |NULL |NULL |NO D |DECIMAL |2 |10 |5 |NULL |NULL |YES TEST |VARCHAR |NULL|NULL|20 |NULL |40 |YES ij> – should find the table, as quoted string case is preserved. describe 'CamelCaseTable'; JAVA ERROR: java.lang.NullPointerException ij> – should fail, as case is wrong: describe 'CAMELCaseTable'; JAVA ERROR: java.lang.NullPointerException ij> – should work, note that schema name must be upper case: describe 'APP.CamelCaseTable'; JAVA ERROR: java.lang.NullPointerException ij> set SCHEMA USER1; 0 rows inserted/updated/deleted ij> – should work, even after changing default schema, so long as schema is right describe 'APP.CamelCaseTable'; JAVA ERROR: java.lang.NullPointerException ij> – should fail, since table is in the other schema describe 'CamelCaseTable'; JAVA ERROR: java.lang.NullPointerException ij> – Can use * as a wildcard for table name: describe '*'; JAVA ERROR: java.lang.NullPointerException ij> describe 'APP.*'; JAVA ERROR: java.lang.NullPointerException ij> – Observe behavior with empty string: describe ''; JAVA ERROR: java.lang.NullPointerException ij>
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda,

        I am not sure why the BootLock test is failing for you. It is a new test in mainline,
        and I'm not completely familiar with it. It looks like the code in the test:

        int port = TestConfiguration.getCurrent().getPort();
        cmd[2] = (new Integer(port)).toString();

        computed an input string of "" for your port number, since the error was:

        Exception in thread "main" java.lang.NumberFormatException: For input string: ""

        Maybe somebody who is familiar with BootLockTest can spot why it couldn't
        figure out your port number.

        The failures in ij7 test look like they could be related to your patch; the output
        contains: JAVA ERROR: java.lang.NullPointerException

        Somewhere in a subdirectory of the place where you ran your junit tests there
        should be some output files which recorded the results of the run of the ij7
        tests, and in those files you should be able to find the complete stack trace.

        Try running something like:

        find . -exec grep NullPointerException {} \; -print

        in the location where you ran your junit tests, and see if the file turns up.

        Show
        Bryan Pendleton added a comment - Hi Eranda, I am not sure why the BootLock test is failing for you. It is a new test in mainline, and I'm not completely familiar with it. It looks like the code in the test: int port = TestConfiguration.getCurrent().getPort(); cmd [2] = (new Integer(port)).toString(); computed an input string of "" for your port number, since the error was: Exception in thread "main" java.lang.NumberFormatException: For input string: "" Maybe somebody who is familiar with BootLockTest can spot why it couldn't figure out your port number. The failures in ij7 test look like they could be related to your patch; the output contains: JAVA ERROR: java.lang.NullPointerException Somewhere in a subdirectory of the place where you ran your junit tests there should be some output files which recorded the results of the run of the ij7 tests, and in those files you should be able to find the complete stack trace. Try running something like: find . -exec grep NullPointerException {} \; -print in the location where you ran your junit tests, and see if the file turns up.
        Hide
        Eranda Sooriyabandara added a comment - - edited

        Hi Bryan,
        Here I am attaching the results I got after doing derbyall test and JUnit tests. There are some exceptions thrown in JUnit tests. I am looking forward to see what they are and inform you soon.

        Show
        Eranda Sooriyabandara added a comment - - edited Hi Bryan, Here I am attaching the results I got after doing derbyall test and JUnit tests. There are some exceptions thrown in JUnit tests. I am looking forward to see what they are and inform you soon.
        Hide
        Bryan Pendleton added a comment -

        It looks like maybe you ran the derbyall tests in a "dirty" directory; that is,
        a directory in which you had previously been running Derby tests?

        If you run the derbyall tests again, with your classpath containing your
        modified code, but the current directory set to a brand-new test directory,
        are your test results any better?

        You can also run the junit tests, in addition to the derbyall tests.

        Here's the command I use to run all the tests, after I first 'cd' into a brand
        new test directory, with my CLASSPATH all set up:

        java org.apache.derbyTesting.functionTests.harness.RunSuite derbyall; java -Xmx512m -XX:MaxPermSize=128m junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All >junitAll.out 2>&1

        Show
        Bryan Pendleton added a comment - It looks like maybe you ran the derbyall tests in a "dirty" directory; that is, a directory in which you had previously been running Derby tests? If you run the derbyall tests again, with your classpath containing your modified code, but the current directory set to a brand-new test directory, are your test results any better? You can also run the junit tests, in addition to the derbyall tests. Here's the command I use to run all the tests, after I first 'cd' into a brand new test directory, with my CLASSPATH all set up: java org.apache.derbyTesting.functionTests.harness.RunSuite derbyall; java -Xmx512m -XX:MaxPermSize=128m junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All >junitAll.out 2>&1
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        I did derbyall test and saw that there are few errors. But I didn't think that they are related to my changes. Here I am attaching the test report file.
        What you think?

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, I did derbyall test and saw that there are few errors. But I didn't think that they are related to my changes. Here I am attaching the test report file. What you think?
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda, Glad to hear the change is working for you too.

        I think that, to start with, we should have tests for DESCRIBE and for
        SHOW, with both table names and schema names using keywords.

        So, how about:

        • describe run
        • show indexes from run
        • describe nohold.execute
        • show views in nohold

        If you think of other tests along these lines, that would be great,
        but this would be a fine start to add to the test suites.

        Have you run any of the existing test suites with the modified parser?

        Show
        Bryan Pendleton added a comment - Hi Eranda, Glad to hear the change is working for you too. I think that, to start with, we should have tests for DESCRIBE and for SHOW, with both table names and schema names using keywords. So, how about: describe run show indexes from run describe nohold.execute show views in nohold If you think of other tests along these lines, that would be great, but this would be a fine start to add to the test suites. Have you run any of the existing test suites with the modified parser?
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        Yes it works with me perfectly. Thanks for the changes.
        What about the test??

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, Yes it works with me perfectly. Thanks for the changes. What about the test??
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda,

        I think your change to caIdentifier is working. Perhaps you had a build
        problem when you tried it? I tried your change and it seemed to work
        for me.

        I modified the patch slightly, to fix the indentation, and to make sure
        that the checks for DatabaseMetadata were done for both the keyword
        and identifier cases, and have attached the revised patch as
        caidentifier.diff.

        Please try applying this patch and see if it works for you.

        Show
        Bryan Pendleton added a comment - Hi Eranda, I think your change to caIdentifier is working. Perhaps you had a build problem when you tried it? I tried your change and it seemed to work for me. I modified the patch slightly, to fix the indentation, and to make sure that the checks for DatabaseMetadata were done for both the keyword and identifier cases, and have attached the revised patch as caidentifier.diff. Please try applying this patch and see if it works for you.
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        I fix the problem which I missed parenthesis. Also I did some basic tests and they passed.
        Here I am attaching the patch file. Also I can create test which runs on ij. Can you clarify which tests do I need to include there.
        Thanks
        Eranda

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, I fix the problem which I missed parenthesis. Also I did some basic tests and they passed. Here I am attaching the patch file. Also I can create test which runs on ij. Can you clarify which tests do I need to include there. Thanks Eranda
        Hide
        Bryan Pendleton added a comment -

        Can you post the change that you tried in caIdentifier?

        Show
        Bryan Pendleton added a comment - Can you post the change that you tried in caIdentifier?
        Hide
        Eranda Sooriyabandara added a comment -

        Hi,
        I tried to add the keyword to caIndetifier() but when the table name is a keyword for example "RUN" caIdentifier() does not called. So can't use keywords inside of caIdentifier(). So I use your method to fix it. It works properly in my machine. Need a feedback before proceeding to test for ambiguities in the grammar.
        Thanks

        Show
        Eranda Sooriyabandara added a comment - Hi, I tried to add the keyword to caIndetifier() but when the table name is a keyword for example "RUN" caIdentifier() does not called. So can't use keywords inside of caIdentifier(). So I use your method to fix it. It works properly in my machine. Need a feedback before proceeding to test for ambiguities in the grammar. Thanks
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        Yes I am quite happy to try on it.
        Thanks
        Eranda

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, Yes I am quite happy to try on it. Thanks Eranda
        Hide
        Bryan Pendleton added a comment -

        Thanks for catching my old client, Knut Anders; I was indeed quite out of date.

        I think the suggestion to add keywords to caIdentifier() is a good one; Eranda,
        do you want to give that a try?

        Show
        Bryan Pendleton added a comment - Thanks for catching my old client, Knut Anders; I was indeed quite out of date. I think the suggestion to add keywords to caIdentifier() is a good one; Eranda, do you want to give that a try?
        Hide
        Knut Anders Hatlen added a comment -

        Hi Bryan,

        The patch seems to have been generated against a fairly old copy of trunk, and it does not apply cleanly because of the changes in DERBY-4430. Also, in the spirit of DERBY-4430, we may want to check the meta-data for the underlying DBMS instead of unconditionally converting the keyword to upper case, see the caIdentifier() method introduced in that issue.

        Perhaps it's even safe to add keywords to caIdentifier(). It's not used many places, so it shouldn't be too much work to go through its usages and check if adding keywords to it would introduce any ambiguities in the grammar. The advantage of adding it to caIdentifier() is that it will then also work for other ij commands than DESCRIBE. For instance, "show indexes from run" would start working.

        Show
        Knut Anders Hatlen added a comment - Hi Bryan, The patch seems to have been generated against a fairly old copy of trunk, and it does not apply cleanly because of the changes in DERBY-4430 . Also, in the spirit of DERBY-4430 , we may want to check the meta-data for the underlying DBMS instead of unconditionally converting the keyword to upper case, see the caIdentifier() method introduced in that issue. Perhaps it's even safe to add keywords to caIdentifier(). It's not used many places, so it shouldn't be too much work to go through its usages and check if adding keywords to it would introduce any ambiguities in the grammar. The advantage of adding it to caIdentifier() is that it will then also work for other ij commands than DESCRIBE. For instance, "show indexes from run" would start working.
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda,

        Here is a diff with an idea that might be worth pursuing. It changes the
        behavior of the DESCRIBE statement so that, in addition to the identifier
        or quoted string that it could take before, it now can also take a keyword,
        which it then upper-cases and tries to use as a table name.

        The patch isn't elegant, but it seems to make 'DESCRIBE RUN' work to
        describe a table named 'run'.

        If you think this idea has merit, then the next step, I think, would be to
        do some more testing, and turn this simple diff into a complete patch
        by adding a variety of test cases which show how the new code behaves.

        Also, I think some additional work would be needed to be able to describe
        a table with the same name as an ij keyword, but in a non-default schema
        (as in 'DESCRIBE bryan.run' to describe the table named 'run' in the schema
        named 'bryan').

        Let me know what you think of this idea.

        Show
        Bryan Pendleton added a comment - Hi Eranda, Here is a diff with an idea that might be worth pursuing. It changes the behavior of the DESCRIBE statement so that, in addition to the identifier or quoted string that it could take before, it now can also take a keyword, which it then upper-cases and tries to use as a table name. The patch isn't elegant, but it seems to make 'DESCRIBE RUN' work to describe a table named 'run'. If you think this idea has merit, then the next step, I think, would be to do some more testing, and turn this simple diff into a complete patch by adding a variety of test cases which show how the new code behaves. Also, I think some additional work would be needed to be able to describe a table with the same name as an ij keyword, but in a non-default schema (as in 'DESCRIBE bryan.run' to describe the table named 'run' in the schema named 'bryan'). Let me know what you think of this idea.
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Bryan,
        I compare describe statement for the tables "run" and "t1" (a normal table).
        Up to runScriptGuts() method in utilMain class both are executed in same manner according to the stack trace. So I step into code after that method. The main difference of executing these two table was in the line 341 in utilMain class "describe run" statement throws an exception. Here I am attaching the step log up to throw the exception. (I thought it will more helpful than stack trace).
        thanks

        Show
        Eranda Sooriyabandara added a comment - Hi Bryan, I compare describe statement for the tables "run" and "t1" (a normal table). Up to runScriptGuts() method in utilMain class both are executed in same manner according to the stack trace. So I step into code after that method. The main difference of executing these two table was in the line 341 in utilMain class "describe run" statement throws an exception. Here I am attaching the step log up to throw the exception. (I thought it will more helpful than stack trace). thanks
        Hide
        Bryan Pendleton added a comment -

        Hi Eranda,
        What is the full stack trace when the "describe run" error is generated?

        Show
        Bryan Pendleton added a comment - Hi Eranda, What is the full stack trace when the "describe run" error is generated?
        Hide
        Eranda Sooriyabandara added a comment -

        Hi Sylvain, Knut,
        When executing the "describe run", the error occurs before parse to JDBC. It resolve there and when it executing the run because the run is a keyword, it add a error token except the run.
        This happens when the executing ij.jj_rescan_token() method line 8103.
        That's how I understood.
        I am I still in the wrong path??

        Show
        Eranda Sooriyabandara added a comment - Hi Sylvain, Knut, When executing the "describe run", the error occurs before parse to JDBC. It resolve there and when it executing the run because the run is a keyword, it add a error token except the run. This happens when the executing ij.jj_rescan_token() method line 8103. That's how I understood. I am I still in the wrong path??
        Hide
        Knut Anders Hatlen added a comment -

        I think what Sylvain said above is correct. Also, the reason why "create table run(a int)" does not fail, is that everything that does not match ij's grammar, is believed to be SQL and passed on to the JDBC driver as it is. That's the same thing that's happens with "describe run", by the way. It is not recognized as an ij command, so it's executed as an SQL statement instead, and fails because Derby's SQL does not support DESCRIBE statements.

        Show
        Knut Anders Hatlen added a comment - I think what Sylvain said above is correct. Also, the reason why "create table run(a int)" does not fail, is that everything that does not match ij's grammar, is believed to be SQL and passed on to the JDBC driver as it is. That's the same thing that's happens with "describe run", by the way. It is not recognized as an ij command, so it's executed as an SQL statement instead, and fails because Derby's SQL does not support DESCRIBE statements.
        Hide
        Sylvain Leroux added a comment -

        Hi Eranda,

        'RUN' is a keyword used by ij.
        http://db.apache.org/derby/papers/DerbyTut/ij_intro.html#Run+SQL+Scripts

        The problem here is that if, in ij, you type a command like 'DESCRIBE RUN', the word RUN is recognized by the JavaCC tokenizer as a keyword. Not an identifier.

        You might have to check - but it could be exactly the same for any other table having a keyword for name. It is even quite possible, each time we add a new keyword in ij, things are going worst!

        One option could be to change the identifier() production to accept keywords. But, this require a closer look, since by doing so, we might introduce ambiguities in the grammar.

        Hope this helps,

        • Sylvain
        Show
        Sylvain Leroux added a comment - Hi Eranda, 'RUN' is a keyword used by ij. http://db.apache.org/derby/papers/DerbyTut/ij_intro.html#Run+SQL+Scripts The problem here is that if, in ij, you type a command like 'DESCRIBE RUN', the word RUN is recognized by the JavaCC tokenizer as a keyword. Not an identifier. You might have to check - but it could be exactly the same for any other table having a keyword for name. It is even quite possible, each time we add a new keyword in ij, things are going worst! One option could be to change the identifier() production to accept keywords. But, this require a closer look, since by doing so, we might introduce ambiguities in the grammar. Hope this helps, Sylvain
        Hide
        Eranda Sooriyabandara added a comment -

        Hi,
        I step to the code and found out that RUN is a ij keyword . (ij.java line 3398). But somehow it skipped when executing the create table run(a int);. What can we do for this? Also I like to know where is this RUN keyword used? Do we want to remove it or can we restrict creating a table named run?

        Show
        Eranda Sooriyabandara added a comment - Hi, I step to the code and found out that RUN is a ij keyword . (ij.java line 3398). But somehow it skipped when executing the create table run(a int);. What can we do for this? Also I like to know where is this RUN keyword used? Do we want to remove it or can we restrict creating a table named run?
        Hide
        Bryan Pendleton added a comment -

        As a workaround,

        describe 'RUN';

        appears to work as desired.

        Show
        Bryan Pendleton added a comment - As a workaround, describe 'RUN'; appears to work as desired.
        Hide
        Rick Hillegas added a comment -

        Triaged for 10.5.2: noted that repro is available, recommended to newcomers.

        Show
        Rick Hillegas added a comment - Triaged for 10.5.2: noted that repro is available, recommended to newcomers.
        Hide
        Kathey Marsden added a comment -

        Unassigning due to inactivity.

        Show
        Kathey Marsden added a comment - Unassigning due to inactivity.
        Hide
        Kathey Marsden added a comment -

        Sandeep, are you still working on this issue? If not can you unassign yourself?

        Show
        Kathey Marsden added a comment - Sandeep, are you still working on this issue? If not can you unassign yourself?
        Hide
        Tim Halloran added a comment -

        upps the steps should be:

        ij> create table run (i int);
        0 rows inserted/updated/deleted
        ij> describe run;
        ERROR 42X01: Syntax error: Encountered "describe" at line 1, column 1.

        I always type "desc" rather than "describe" (ye olde Oracle habit

        Show
        Tim Halloran added a comment - upps the steps should be: ij> create table run (i int); 0 rows inserted/updated/deleted ij> describe run; ERROR 42X01: Syntax error: Encountered "describe" at line 1, column 1. I always type "desc" rather than "describe" (ye olde Oracle habit

          People

          • Assignee:
            Eranda Sooriyabandara
            Reporter:
            Tim Halloran
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development