[jira] [Updated] (DERBY-693) Incorrect line number in the error message when parser throws syntax error in some specific examples
[ https://issues.apache.org/jira/browse/DERBY-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-693: -- Assignee: Leshan Bashitha Wijegunawardana > Incorrect line number in the error message when parser throws syntax error in > some specific examples > > > Key: DERBY-693 > URL: https://issues.apache.org/jira/browse/DERBY-693 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6 >Reporter: Mamta A. Satoor >Assignee: Leshan Bashitha Wijegunawardana >Priority: Minor > Labels: derby_triage10_5_2 > Attachments: w.sql > > > After connecting to a database through ij, parser returns correct line number > for the sql "select" the first time around but it returns incorrect line > number when the same sql is rexecuted, as shown below > $ java org.apache.derby.tools.ij > ij version 10.2 > ij> connect 'jdbc:derby:c:/dellater/db1'; > ij> select > ; > ERROR 42X01: Syntax error: Encountered "" at line 1, column 8. > ij> select > ; > ERROR 42X01: Syntax error: Encountered "" at line 2, column 8. > ij> > This is caused by UCode_CharStream's UpdateLineColumn method. When the sql > "select" is executed the first time, the parser comes to UpdateLineColumn > method for trailing \r and then for trailing \n for the first line "select". > The trailing \n causes the prevCharIsLF to be set to true. Since this sql is > incorrect by itself, parser will throw a syntax error. After the exception > and before the processing of next sql "select", this prevCharIsLF flag does > not get set to false(this is the problem). When the first character "s" is > read, UpdateLineColumn checks if prevCharIsLF set to true and if yes, it > increments(incorrectly) the line number to 2 and that is why the second time > around, execution of "select" gives syntax error at line 2 rather than line 1. > This also causes problem with the optimizer hints when they are used in > incorrect context as shown below. > $ java org.apache.derby.tools.ij > ij version 10.2 > ij> connect 'jdbc:derby:c:/dellater/db1'; > ij> -- derby-properties > select * from t1; > ERROR 42X01: Syntax error: Encountered "derby-properties" at line 1, column 4. > ij> -- derby-properties > select * from t1; > ERROR 42X01: Syntax error: Encountered "derby-properties" at line 2, column 4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Backspace and arrow keys don't work in ij tool
On 8/3/2016 8:44 PM, Leshan Bashitha Wijegunawardana wrote: It's really difficult when writing sql commands when important keys such as backspace and arrow keys don't work in the ij tool. I see this as a bug in the ij tool. Many people, over the years, have found this quite frustrating. I encourage you to spend some time reviewing: https://issues.apache.org/jira/browse/DERBY-1447 thanks, bryan
[jira] [Commented] (DERBY-693) Incorrect line number in the error message when parser throws syntax error in some specific examples
[ https://issues.apache.org/jira/browse/DERBY-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407146#comment-15407146 ] Amelia Garripoli commented on DERBY-693: Thank you for your email. This is an automated reply. I don't work during summer term and will be available again on September 2, 2016. If you are seeking advising, please contact the Advising & Counseling Center, Room HSS-203G on the Bremerton campus. The primary Entry Advisor for all CIS programs is Steve Quinn (squ...@olympic.edu). To make an advising appointment contact him directly or call the Advising & Counseling Center at 360-475-7530. Additional information about CIS programs and the BAS-IS program can be found at the CIS "Digital Advisor" at http://cis2.oc.ctc.edu/oc_apps/CIS/da/cisadvisor.php If you need immediate assistance on anything else, please contact the Business & Technology division office at 360-475-7360. See you in September, ~Amelia. Amelia Garripoli, Professor, Information Systems Olympic College, 1600 Chester Avenue, Bremerton, WA 98337 agarrip...@olympic.edu, (360) 475-7588, TEC-210 http://faculty.olympic.edu/agarripoli See OC's Bachelor of Applied Science in Information Systems (BAS IS) --- "A world without string is chaos." ~ Rudolf Smuntz, MouseHunt > Incorrect line number in the error message when parser throws syntax error in > some specific examples > > > Key: DERBY-693 > URL: https://issues.apache.org/jira/browse/DERBY-693 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6 >Reporter: Mamta A. Satoor >Priority: Minor > Labels: derby_triage10_5_2 > Attachments: w.sql > > > After connecting to a database through ij, parser returns correct line number > for the sql "select" the first time around but it returns incorrect line > number when the same sql is rexecuted, as shown below > $ java org.apache.derby.tools.ij > ij version 10.2 > ij> connect 'jdbc:derby:c:/dellater/db1'; > ij> select > ; > ERROR 42X01: Syntax error: Encountered "" at line 1, column 8. > ij> select > ; > ERROR 42X01: Syntax error: Encountered "" at line 2, column 8. > ij> > This is caused by UCode_CharStream's UpdateLineColumn method. When the sql > "select" is executed the first time, the parser comes to UpdateLineColumn > method for trailing \r and then for trailing \n for the first line "select". > The trailing \n causes the prevCharIsLF to be set to true. Since this sql is > incorrect by itself, parser will throw a syntax error. After the exception > and before the processing of next sql "select", this prevCharIsLF flag does > not get set to false(this is the problem). When the first character "s" is > read, UpdateLineColumn checks if prevCharIsLF set to true and if yes, it > increments(incorrectly) the line number to 2 and that is why the second time > around, execution of "select" gives syntax error at line 2 rather than line 1. > This also causes problem with the optimizer hints when they are used in > incorrect context as shown below. > $ java org.apache.derby.tools.ij > ij version 10.2 > ij> connect 'jdbc:derby:c:/dellater/db1'; > ij> -- derby-properties > select * from t1; > ERROR 42X01: Syntax error: Encountered "derby-properties" at line 1, column 4. > ij> -- derby-properties > select * from t1; > ERROR 42X01: Syntax error: Encountered "derby-properties" at line 2, column 4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-693) Incorrect line number in the error message when parser throws syntax error in some specific examples
[ https://issues.apache.org/jira/browse/DERBY-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407143#comment-15407143 ] Leshan Bashitha Wijegunawardana commented on DERBY-693: --- I'm a computer engineering undergraduate who is new to the Apache Derby code base. According to the explanation here I understood that this issue can be overcome by setting prevCharIsLF flag to false before calling UpdateLineColumn method. When I go through the UCode_CharStream class there is one place that the UpdateLineColumn method is called. That is in the readChar method. So I hope this can be overcome by setting prevCharIsLF flag to false before calling UpdateLineColumn method in the readChar method. Is that ok? Else can anyone explain me the issue liittle bit. Thanks. > Incorrect line number in the error message when parser throws syntax error in > some specific examples > > > Key: DERBY-693 > URL: https://issues.apache.org/jira/browse/DERBY-693 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6 >Reporter: Mamta A. Satoor >Priority: Minor > Labels: derby_triage10_5_2 > Attachments: w.sql > > > After connecting to a database through ij, parser returns correct line number > for the sql "select" the first time around but it returns incorrect line > number when the same sql is rexecuted, as shown below > $ java org.apache.derby.tools.ij > ij version 10.2 > ij> connect 'jdbc:derby:c:/dellater/db1'; > ij> select > ; > ERROR 42X01: Syntax error: Encountered "" at line 1, column 8. > ij> select > ; > ERROR 42X01: Syntax error: Encountered "" at line 2, column 8. > ij> > This is caused by UCode_CharStream's UpdateLineColumn method. When the sql > "select" is executed the first time, the parser comes to UpdateLineColumn > method for trailing \r and then for trailing \n for the first line "select". > The trailing \n causes the prevCharIsLF to be set to true. Since this sql is > incorrect by itself, parser will throw a syntax error. After the exception > and before the processing of next sql "select", this prevCharIsLF flag does > not get set to false(this is the problem). When the first character "s" is > read, UpdateLineColumn checks if prevCharIsLF set to true and if yes, it > increments(incorrectly) the line number to 2 and that is why the second time > around, execution of "select" gives syntax error at line 2 rather than line 1. > This also causes problem with the optimizer hints when they are used in > incorrect context as shown below. > $ java org.apache.derby.tools.ij > ij version 10.2 > ij> connect 'jdbc:derby:c:/dellater/db1'; > ij> -- derby-properties > select * from t1; > ERROR 42X01: Syntax error: Encountered "derby-properties" at line 1, column 4. > ij> -- derby-properties > select * from t1; > ERROR 42X01: Syntax error: Encountered "derby-properties" at line 2, column 4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[Java DB - testing] Failure continuous trunk (rev 1755133)
Java DB testing and reporting infrastructure. Failure continuous trunk (rev 1755133) There were 16 failures.
Backspace and arrow keys don't work in ij tool
It's really difficult when writing sql commands when important keys such as backspace and arrow keys don't work in the ij tool. I see this as a bug in the ij tool. Thanks. *Leshan Bashitha Wijegunawardana,* Third Year Undergraduate | Computer Engineering, Faculty of Engineering, University of Peradeniya. Linkedin :- https://www.linkedin.com/in/leshan-bashitha-wijegunawardana-366202b8
Re: Contributing to Apache Derby
My JIRA ID = Bashitha Thanks for the bugs you have given. I'm currently working on https://issues.apache.org/jira/browse/DERBY-693 *Leshan Bashitha Wijegunawardana,* Third Year Undergraduate | Computer Engineering, Faculty of Engineering, University of Peradeniya. Linkedin :- https://www.linkedin.com/in/leshan-bashitha-wijegunawardana-366202b8 On Sun, Jul 24, 2016 at 8:43 PM, Bryan Pendleton wrote: > The above 2 mentioned links for issues seem to be not working since it has >> a private access. >> > > Hmmm... I'm not quite sure what's wrong there. JIRA permissions are a > little > bit odd. Possibly I have to add you to the "derby developers" group in > JIRA. > > What is your JIRA ID? > > I just have built the code base. Can u give some minor issues so that I >> can get the confidence. Is the issue in the following link is ok to start >> up with? >> >> https://issues.apache.org/jira/browse/DERBY-6863 >> > > DERBY-6863 is definitely an important bug, and it would be wonderful > to get somebody working on it. > > However, I worry that it is a pretty hard bug, not so much conceptually > hard, but hard because it requires working in some of the parts of Derby > that aren't terribly easy to understand. > > In particular, Derby implements some of the SQL execution processing > by generating Java bytecode at runtime, and when that bytecode is > generated incorrectly, figuring out why can be very challenging. > > But, by all means, if DERBY-6863 is interesting to you, then it definitely > needs to be fixed! > > If you are looking for some simpler bugs to work on, just to get some > practice with the different pieces of Derby, and how the code fits > together, and how to add new tests and run existing tests, try these: > > https://issues.apache.org/jira/browse/DERBY-6752 > > https://issues.apache.org/jira/browse/DERBY-546 > > https://issues.apache.org/jira/browse/DERBY-693 > > https://issues.apache.org/jira/browse/DERBY-5852 > > thanks, > > bryan > >
[jira] [Resolved] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton resolved DERBY-853. --- Resolution: Fixed Fix Version/s: 10.13.0.0 We've completed all the planned work for this issue. Marking fixed. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Fix For: 10.13.0.0 > > Attachments: BryanPossibleIdea.diff, Derby-853.diff, > Derby-853_2.diff, Derby-853_3.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proposal for a new feature in Apache Derby IJ tool
Note that the owner of the table is the authorization id of the schema containing the table. That is, the following query should show you who owns what tables select s.authorizationID, s.schemaName, t.tableName from sys.sysschemas s, sys.systables t where t.schemaID = s.schemaID I haven't looked closely at how the ij introspection statements are implemented. The original goal of ij was for it to be as database-agnostic as possible. That is, the goal was to be able to deploy ij against any database which has a JDBC driver (and therefore access to a DatabaseMetaData object). I don't see authorization identifiers modelled in the JDK 8 DatabaseMetaData. Thanks, -Rick On 8/3/16, 2:21 PM, Bryan Pendleton wrote: On 8/3/2016 4:57 AM, dulanja mallikarachchi wrote: Hi all, I want to list the tables created by me. I don't think Derby keeps track of which table was created by which user. Is there something that makes you think Derby is keeping track of that? Derby *does* keep track of the *database* owner, but that's a different concept, and applies to the database as a whole, not to individual schema objects. So far as I know. thanks, bryan
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407008#comment-15407008 ] Danoja Dias commented on DERBY-853: --- I think, we can resolve this issue. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: BryanPossibleIdea.diff, Derby-853.diff, > Derby-853_2.diff, Derby-853_3.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15406955#comment-15406955 ] ASF subversion and git services commented on DERBY-853: --- Commit 1755133 from [~bryanpendleton] in branch 'code/trunk' [ https://svn.apache.org/r1755133 ] DERBY-853: ResultSetMetaData.getScale returns inconsistent values This patch was contributed by Danoja Dias (danojadias at gmail dot com) When a SQL statement contains arithmetic expressions, the result of the expression may be of a different type than the operands to the expression, due to type precedence rules which may require promoting the operand values during evaluation of the expression. For example, subtracting a DOUBLE from a DECIMAL results in a DOUBLE. In some of these cases, Derby was reporting that the result column had a non-zero scale, although the result column was not of DECIMAL type. This change modifies the NumericTypeCompiler so that it only computes a non-zero scale for the result column when it is of DECIMAL type. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: BryanPossibleIdea.diff, Derby-853.diff, > Derby-853_2.diff, Derby-853_3.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15406849#comment-15406849 ] Danoja Dias commented on DERBY-853: --- All test are clean in my system too. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: BryanPossibleIdea.diff, Derby-853.diff, > Derby-853_2.diff, Derby-853_3.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proposal for a new feature in Apache Derby IJ tool
On 8/3/2016 4:57 AM, dulanja mallikarachchi wrote: Hi all, I want to list the tables created by me. I don't think Derby keeps track of which table was created by which user. Is there something that makes you think Derby is keeping track of that? Derby *does* keep track of the *database* owner, but that's a different concept, and applies to the database as a whole, not to individual schema objects. So far as I know. thanks, bryan
Re: Security vulnerability in IJ tool - Apache Derby
On 8/3/2016 5:43 AM, dulanja mallikarachchi wrote: Hi All, When a database is created, two files are created inside "log" and "seg0" folders. These files can replaced with other files. Thus database is open to vulnerabilities. If we can restrict access to the above mentioned folders, we can get rid of this vulnerability. Thank you. Thank you for looking into this. What you describe sounds quite similar to DERBY-5363: https://issues.apache.org/jira/browse/DERBY-5363 Perhaps you could describe your issue in more detail, and describe how you think it relates to the work done on DERBY-5363. I.e., - do you think that DERBY-5363 has regressed? - do you think that the fix for DERBY-5363 was inadequate? - do you think that you are seeing a different issue entirely? thanks, bryan
Security vulnerability in IJ tool - Apache Derby
Hi All, When a database is created, two files are created inside "log" and "seg0" folders. These files can be replaced with other files. Thus database is open to vulnerabilities. If we can restrict access to the above mentioned folders, we can get rid of this vulnerability. Thank you.
Security vulnerability in IJ tool - Apache Derby
Hi All, When a database is created, two files are created inside "log" and "seg0" folders. These files can replaced with other files. Thus database is open to vulnerabilities. If we can restrict access to the above mentioned folders, we can get rid of this vulnerability. Thank you.
Proposal for a new feature in Apache Derby IJ tool
Hi all, When I type "show tables" in IJ tool, it lists all the available tables. Rather than listing all the tables available in the database, what if I want to list the tables created by me. I have to list all the tables and filter out my tables. What I suggest is to have a separate command or an option for "show tables" command to list only my tables. Thank you.
