[jira] Commented: (DERBY-1686) Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail
[ http://issues.apache.org/jira/browse/DERBY-1686?page=comments#action_12430941 ] Yip Ng commented on DERBY-1686: --- Please refer to SQL 2003 standard, section 12.1 grant statement, item 4 and 5 under general rules and section 12.2 grant privilege statement, item 6 under general rules for the correct semantics of grantable privileges. Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail --- Key: DERBY-1686 URL: http://issues.apache.org/jira/browse/DERBY-1686 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Any Reporter: Rajesh Kartha Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1686-trunk-diff01.txt, derby1686-trunk-diff02.txt, derby1686-trunk-stat01.txt, derby1686-trunk-stat02.txt, select_table_no_privilege.sql With authentication on, attempting to execute a GRANT privilege to 'user3' on a VIEW created by the 'user2' - who has only SELECT privilege on the base table created by 'user1' does not fail. This results in 'user3' getting access to the table created by 'user1' through the view. I remember a discussion on the list to raise an error when an attempt is execute a GRANT on the view, until WITH GRANT option is implemented. Here is the repro: java -cp derby.jar;.\derbytools.jar -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij select_table_no_privilege.sql ij version 10.2 ij -- --create db as user1 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1(id int); 0 rows inserted/updated/deleted ij insert into t1 values(100); 1 row inserted/updated/deleted ij insert into t1 values(200); 1 row inserted/updated/deleted ij -- --Grant select to user2 -- grant select on t1 to user2; 0 rows inserted/updated/deleted ij -- --Connect as user2 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user2'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existingdatabase instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION1) select * from user1.t1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Create view -- create view v1 as select * from user1.t1; 0 rows inserted/updated/deleted ij(CONNECTION1) select * from v1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Grant select on view to user3. With the WITH GRANT option this should have failed -- grant select on v1 to user3; 0 rows inserted/updated/deleted ij(CONNECTION1) -- --Connect as user3 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user3'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION2) -- --No select privilege on base table user1.t1, hence will FAIL -- select * from user1.t1; ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(Unknown Source) at org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.fillResultSet(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at
[jira] Created: (DERBY-1766) Make test jdbcapi/batachUpdate run in client/server framework
Make test jdbcapi/batachUpdate run in client/server framework - Key: DERBY-1766 URL: http://issues.apache.org/jira/browse/DERBY-1766 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.2.1.0 Environment: Any Reporter: Øystein Grøvlen Priority: Minor The test jdbcapi/batchUpdate.java is disabled in the DerbyNetClient framework. The reason seems to be that you get a general exception, BatchUpdateException, instead of the specific exceptions you get in the embedded framework. The fix for this is probably to unwrap the BatchUpdateException to get to the more specific exception. Since batchUpdate.java does not run in client/server, DERBY-1292 has added a test to derbynet/prepStmt.java that really belongs in batchUpdate. As part of fixing this JIRA, that test, and other similar tests in prepStmt, should be moved to batchUpdate. It also seems like parameterMapping.java had similar problems which was changed by changing the canon to expect BatchUpdateExceptions. In my opinion, one should also unwrap the BatchUpdateExceptions in that test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
Bryan Pendleton wrote: Oystein Grovlen - Sun Norway wrote: Oh, I did not notice this. I tried to run batchUpdate with DerbyNetClient, but this still fails. I guess that means that beetle 5561 is still an issue Perhaps this is worthy of a JIRA issue of its own, something along the lines of: - if you run jdbcapi/batchUpdate with DerbyNetClient, it fails with symptom XXX. As part of fixing this bug, the test case for DERBY-1292 should be moved from jdbcapi/prepStmt.java to jdbc/batchUpdate.java so that it fits more cleanly with the other tests in the test suite. I have files JIRA DERBY-1766 for this. -- Øystein
Regression Test Failure! - Derby 437427 - Sun DBTG
[Auto-generated mail] *Derby* 437427/2006-08-27 19:47:32 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* NA NA NANA SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-437427.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/437427.html *Jvm: 1.5* 0672672 2 111.45% CYGWIN_NT-5.1_i686-unknown 3672669 2 125.68% CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 0672672 2 106.90% Linux-2.6.9-34.ELsmp_x86_64-x86_64 1672671 2 231.56% SunOS-5.10_i86pc-i386 0672672 2 138.12% SunOS-5.10_sun4u-sparc 0672672 2 109.11% SunOS-5.11_i86pc-i386 1672671 2 113.40% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-437427.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/437427.html *Jvm: 1.4* 0666666 4 105.98% CYGWIN_NT-5.1_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 0666666 4 120.78% Linux-2.6.9-34.ELsmp_x86_64-x86_64 1666665 4 202.60% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-437427.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/437427.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/437427.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB
[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Attachment: DERBY-1559v5.diff Attached patch makes DDMReader handle the DRDAProtocolException, and throws IOException from it, instead of doing it from the stream class. when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB Key: DERBY-1559 URL: http://issues.apache.org/jira/browse/DERBY-1559 Project: Derby Issue Type: Sub-task Components: Network Server Affects Versions: 10.2.1.0, 10.3.0.0, 10.2.2.0 Reporter: Andreas Korneliussen Assigned To: Andreas Korneliussen Attachments: DERBY-1559.diff, DERBY-1559.stat, DERBY-1559v2.diff, DERBY-1559v3.diff, DERBY-1559v4.diff, DERBY-1559v5.diff, serverMemoryUsage.xls When streaming a BLOB from the Network Client to the Network Server, the Network server currently read all the data from the stream and put it into a byte array. The blob data is then inserted into the DB by using PreparedStatement.setBytes(..) and later PreparedStatement.execute() To avoid OutOfMemoryError if the size of the Blob is than total memory in the VM, we could make the network server create a stream which reads data when doing PreparedStatement.execute(). The DB will then stream the BLOB data directly from the network inputstream into the disk. I intent to make a patch which does this if there is only one EXTDTA object (BLOB) sent from the client in the statement, as it will simplify the implementation. Later this can be improved further to include CLOBs, and possibly to include the cases where there are multiple EXTDTA objects. -- CLOBs are more complex, as there need to be some character encoding. This can be achieved by using a InputStreamReader, and use PreparedStatement.setCharacterStream(..). However the size of the stream is not necessarily the same as the size of the raw binary data, and to do this for CLOBs, I would need the embedded prepared statements to support the new setCharacterStream() overloads in JDBC4 (which do not include a length atribute) -- Multiple EXTDATA objects are also more complex, since one would need to have fully read the previous object ,before it is possible to read the next. -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset
Mike Matrigali wrote: Andreas Korneliussen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1696?page=all ] Andreas Korneliussen updated DERBY-1696: Component/s: Store To fix this issue, I need a mechanism to notify the store (scancontroller) to move off the row (i.e to afterLast() or beforeFirst()), so that it can release the lock on the current row. I do consider the following options: Alternative 1: Use the method ScanController.positionAtRowLocation(RowLocation rl) Here the RowLocation objects could represent the positions beforeFirst and afterLast. I.e one could make use of the RecordHandle. RESERVED4_RECORD_HANDLE and RecordHandle. RESERVED4_RECORD_HANDLE to represent to beforeFirst and afterLast positions. When the method ScanController.positionAtRowLocation(RowLocation rl), is called with a rowlocation with these positions, the scan implementation may release the U-lock of the current row Alternative 2: Add new methods to ScanController interface: moveToAfterLast() and moveToBeforeFirst() Can you just close the scan if you don't need it positioned anymore? I'll check if that works Regards Andreas signature.asc Description: OpenPGP digital signature
[jira] Created: (DERBY-1767) insertRow(), updateRow() and deleteRow() cannot handle table names and column names containing double quotes
insertRow(), updateRow() and deleteRow() cannot handle table names and column names containing double quotes Key: DERBY-1767 URL: http://issues.apache.org/jira/browse/DERBY-1767 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.2.1 Reporter: Knut Anders Hatlen Priority: Minor Attachments: QuotesInNames.java ResultSet.insertRow(), ResultSet.updateRow() and ResultSet.deleteRow() fail with syntax error if the table name or a column name contains a double quote character. The attached repro gives this stack trace: Exception in thread main java.sql.SQLSyntaxErrorException: Syntax error: Encountered quoted at line 1, column 24. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:137) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:72) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:203) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:380) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:345) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1378) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4342) at org.apache.derby.impl.jdbc.EmbedResultSet.insertRow(EmbedResultSet.java:3678) at QuotesInNames.main(QuotesInNames.java:15) Caused by: java.sql.SQLException: Syntax error: Encountered quoted at line 1, column 24. ... 11 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1768) Remove JDBC 4.0 RowId classes
Remove JDBC 4.0 RowId classes - Key: DERBY-1768 URL: http://issues.apache.org/jira/browse/DERBY-1768 Project: Derby Issue Type: Improvement Affects Versions: 10.2.1.0 Reporter: Knut Anders Hatlen Priority: Minor JDBC 4.0 introduced the java.sql.RowId interface. Derby has implemented this interface both in the client driver and the embedded driver, but the methods only throw java.lang.UnsupportedOperationException, and an application has no way to get a RowId object. To reduce the footprint, these unused classes should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1768) Remove JDBC 4.0 RowId classes
[ http://issues.apache.org/jira/browse/DERBY-1768?page=all ] Knut Anders Hatlen updated DERBY-1768: -- Attachment: rowid.diff rowid.stat Attached a patch which removes org.apache.derby.impl.jdbc.EmbedRowId and org.apache.derby.client.am.RowId. Derbyall ran cleanly on jdk1.6 (except TestQueryObject which fails because of a bug in the jdk). Remove JDBC 4.0 RowId classes - Key: DERBY-1768 URL: http://issues.apache.org/jira/browse/DERBY-1768 Project: Derby Issue Type: Improvement Affects Versions: 10.2.1.0 Reporter: Knut Anders Hatlen Priority: Minor Attachments: rowid.diff, rowid.stat JDBC 4.0 introduced the java.sql.RowId interface. Derby has implemented this interface both in the client driver and the embedded driver, but the methods only throw java.lang.UnsupportedOperationException, and an application has no way to get a RowId object. To reduce the footprint, these unused classes should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1768) Remove JDBC 4.0 RowId classes
[ http://issues.apache.org/jira/browse/DERBY-1768?page=all ] Knut Anders Hatlen updated DERBY-1768: -- Assignee: Knut Anders Hatlen Derby Info: [Patch Available] Remove JDBC 4.0 RowId classes - Key: DERBY-1768 URL: http://issues.apache.org/jira/browse/DERBY-1768 Project: Derby Issue Type: Improvement Affects Versions: 10.2.1.0 Reporter: Knut Anders Hatlen Assigned To: Knut Anders Hatlen Priority: Minor Attachments: rowid.diff, rowid.stat JDBC 4.0 introduced the java.sql.RowId interface. Derby has implemented this interface both in the client driver and the embedded driver, but the methods only throw java.lang.UnsupportedOperationException, and an application has no way to get a RowId object. To reduce the footprint, these unused classes should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset
Can you just close the scan if you don't need it positioned anymore?
I'll check if that works
The problem is that we need it re-positioned later, i.e if the user
moves to the afterLast() position and then scrolls to any other row, we
need to lock that row.
If the scan has been closed with close(), we cannot reopen it. If it has
been closed with closeForEndTransaction(.) we may reopen it, however
that would be quite undesirable, since we are not ending the
transaction, and we do not access the scancontroller from ScanManager
(which has closeForEndTransaction(.).
An alternative which I have considered is to make
ScanController.positionAtRowLocation(..) handle this by adding semantics
to the RowLocation being NULL.
I.e in HeapScan.java add this:
public boolean positionAtRowLocation(RowLocation rl) throws
StandardException {
if (rl==null)
{
positionAtDoneScan(scan_position);
return(false);
}
positionAtDoneScan will set the scan state to SCAN_DONE and release lock
as desired.
Andreas
signature.asc
Description: OpenPGP digital signature
[jira] Commented: (DERBY-1533) ArrayIndexOutOfBoundsException in DDMReader, on a specific data size
[ http://issues.apache.org/jira/browse/DERBY-1533?page=comments#action_12430970 ] Wiktor Lisowicz commented on DERBY-1533: OK, works for me. ArrayIndexOutOfBoundsException in DDMReader, on a specific data size Key: DERBY-1533 URL: http://issues.apache.org/jira/browse/DERBY-1533 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.1.3.1, 10.1.2.1 Environment: - Derby Network Server Information Version: CSS10011/10.1.3.1 Build: 417277 DRDA Product Id: CSS10011 -- listing properties -- derby.drda.maxThreads=0 derby.drda.keepAlive=true derby.drda.minThreads=0 derby.drda.portNumber=1527 derby.drda.logConnections=false derby.drda.timeSlice=0 derby.drda.startNetworkServer=false derby.drda.host=localhost derby.drda.traceAll=false -- Java Information -- Java Version:1.4.2_08 Java Vendor: Sun Microsystems Inc. OS name: Windows XP OS architecture: x86 OS version: 5.1 java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\dev\derby\lib\derby.jar] 10.1.3.1 - (417277) [C:\dev\derby\lib\derbytools.jar] 10.1.3.1 - (417277) [C:\dev\derby\lib\derbynet.jar] 10.1.3.1 - (417277) -- Reporter: Wiktor Lisowicz Assigned To: Bryan Pendleton Fix For: 10.2.1.0 Attachments: ddmreader1.diff, DerbyTest.java, DerbyTest2.java, notes.html, withTests.diff As far as I know, this bug is not related to DERBY-428 bug. I got this bug both on 10.1.3.1 and 10.1.2.1 - an ArrayIndexOutOfBoundsException in DDMReader (in Network Server). To reproduce the bug: 1. Compile the attached DerbyTest.java 2. Start the Network Server (startNetworkServer.bat under Windows) 3. Run: java DerbyTest On client side you get: org.apache.derby.client.am.DisconnectException: The DDM object is not supported. Unsupported DDM object code point: 0x0 at org.apache.derby.client.net.NetConnectionReply.doObjnsprmSemantics(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseCommonError(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parseExecuteError(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown Source) at org.apache.derby.client.net.NetStatementReply.readExecute(Unknown Source) at org.apache.derby.client.net.StatementReply.readExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.readExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.readExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.execute(Unknown Source) at DerbyTest.main(DerbyTest.java:479) On server side you get: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.derby.impl.drda.DDMReader.compressBLayerData(Unknown Source) at org.apache.derby.impl.drda.DDMReader.ensureBLayerDataInBuffer(Unknown Source) at org.apache.derby.impl.drda.DDMReader.readNetworkShort(Unknown Source) at org.apache.derby.impl.drda.DDMReader.readLDStringData(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.readAndSetParams(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) agentThread[DRDAConnThread_11,5,main] null java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.derby.impl.drda.DDMReader.compressBLayerData(Unknown Source) at org.apache.derby.impl.drda.DDMReader.ensureBLayerDataInBuffer(Unknown Source) at org.apache.derby.impl.drda.DDMReader.readNetworkShort(Unknown Source) at org.apache.derby.impl.drda.DDMReader.readLDStringData(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.readAndSetParams(Unknown Source) at
RE: [jira] Resolved: (DERBY-1533) ArrayIndexOutOfBoundsException in DDMReader, on a specific data size
Hi, I would like to close the bug, but I'm afraid I don;t have the privileges, so maybe you could do it yourself? And I have one question: do you plan any official release, with the fix of this bug, in the nearest future? regards, Wiktor -Original Message- From: Bryan Pendleton (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 5:45 PM To: Wiktor Lisowicz Subject: [jira] Resolved: (DERBY-1533) ArrayIndexOutOfBoundsException in DDMReader, on a specific data size [ http://issues.apache.org/jira/browse/DERBY-1533?page=all ] Bryan Pendleton resolved DERBY-1533. Fix Version/s: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Committed the withTests patch to subversion as revision 430077. Cleared the patch available flag, and marked as resolved in 10.2. Wiktor, if you could please verify that this problem has been fixed in your environment, and then close the bug if true, that would be great. ArrayIndexOutOfBoundsException in DDMReader, on a specific data size Key: DERBY-1533 URL: http://issues.apache.org/jira/browse/DERBY-1533 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.1.2.1, 10.1.3.1 Environment: - Derby Network Server Information Version: CSS10011/10.1.3.1 Build: 417277 DRDA Product Id: CSS10011 -- listing properties -- derby.drda.maxThreads=0 derby.drda.keepAlive=true derby.drda.minThreads=0 derby.drda.portNumber=1527 derby.drda.logConnections=false derby.drda.timeSlice=0 derby.drda.startNetworkServer=false derby.drda.host=localhost derby.drda.traceAll=false -- Java Information -- Java Version:1.4.2_08 Java Vendor: Sun Microsystems Inc. OS name: Windows XP OS architecture: x86 OS version: 5.1 java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\dev\derby\lib\derby.jar] 10.1.3.1 - (417277) [C:\dev\derby\lib\derbytools.jar] 10.1.3.1 - (417277) [C:\dev\derby\lib\derbynet.jar] 10.1.3.1 - (417277) -- Reporter: Wiktor Lisowicz Assigned To: Bryan Pendleton Fix For: 10.2.0.0 Attachments: ddmreader1.diff, DerbyTest.java, DerbyTest2.java, notes.html, withTests.diff As far as I know, this bug is not related to DERBY-428 bug. I got this bug both on 10.1.3.1 and 10.1.2.1 - an ArrayIndexOutOfBoundsException in DDMReader (in Network Server). To reproduce the bug: 1. Compile the attached DerbyTest.java 2. Start the Network Server (startNetworkServer.bat under Windows) 3. Run: java DerbyTest On client side you get: org.apache.derby.client.am.DisconnectException: The DDM object is not supported. Unsupported DDM object code point: 0x0 at org.apache.derby.client.net.NetConnectionReply.doObjnsprmSemantics(Unkno wn Source) at org.apache.derby.client.net.NetConnectionReply.parseCommonError(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parseExecuteError(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknow n Source) at org.apache.derby.client.net.NetStatementReply.readExecute(Unknown Source) at org.apache.derby.client.net.StatementReply.readExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.readExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.readExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.execute(Unknown Source) at DerbyTest.main(DerbyTest.java:479) On server side you get: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.derby.impl.drda.DDMReader.compressBLayerData(Unknown Source) at org.apache.derby.impl.drda.DDMReader.ensureBLayerDataInBuffer(Unknown Source) at org.apache.derby.impl.drda.DDMReader.readNetworkShort(Unknown Source) at org.apache.derby.impl.drda.DDMReader.readLDStringData(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.readAndSetParams(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source) at
Re: are there any publicly available test results for the 10.2 branch?
Thanks, Ole! Ole Solberg wrote: Rick Hillegas wrote: Hi Mike, The good news is that Ole is now running regular regression tests against the head of the 10.2 branch now. However, those results aren't publicly visible yet. I expect them to appear publicly soon. Now available at http://www.multinet.no/~solberg/public/Apache/#10.2Branch Regards, -Rick Mike Matrigali wrote: I was looking for some results for the most up to date branch run - I hit 10 diffs in my newly created branch run and want to figure out if it is my environment or the branch itself. I went to the following and it looks like the last test runs on the 10.2 branch was on the 8/11. http://www.multinet.no/~solberg/public/Apache/10.2.1.0_RC/jvm1.4/Limited/
[jira] Commented: (DERBY-1767) insertRow(), updateRow() and deleteRow() cannot handle table names and column names containing double quotes
[ http://issues.apache.org/jira/browse/DERBY-1767?page=comments#action_12430972 ] Knut Anders Hatlen commented on DERBY-1767: --- Also, when this error is observed, subsequent calls to Connection.rollback() will fail with: java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection. This only happens with insertRow() and deleteRow(), not with updateRow(). I suspect this is because insertRow() and deleteRow() don't call popStatementContext() in their finally clauses. insertRow(), updateRow() and deleteRow() cannot handle table names and column names containing double quotes Key: DERBY-1767 URL: http://issues.apache.org/jira/browse/DERBY-1767 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.2.1 Reporter: Knut Anders Hatlen Priority: Minor Attachments: QuotesInNames.java ResultSet.insertRow(), ResultSet.updateRow() and ResultSet.deleteRow() fail with syntax error if the table name or a column name contains a double quote character. The attached repro gives this stack trace: Exception in thread main java.sql.SQLSyntaxErrorException: Syntax error: Encountered quoted at line 1, column 24. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:137) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:72) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:203) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:380) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:345) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1378) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4342) at org.apache.derby.impl.jdbc.EmbedResultSet.insertRow(EmbedResultSet.java:3678) at QuotesInNames.main(QuotesInNames.java:15) Caused by: java.sql.SQLException: Syntax error: Encountered quoted at line 1, column 24. ... 11 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1766) Make test jdbcapi/batchUpdate run in client/server framework
[ http://issues.apache.org/jira/browse/DERBY-1766?page=all ] John H. Embretsen updated DERBY-1766: - Summary: Make test jdbcapi/batchUpdate run in client/server framework (was: Make test jdbcapi/batachUpdate run in client/server framework) Make test jdbcapi/batchUpdate run in client/server framework Key: DERBY-1766 URL: http://issues.apache.org/jira/browse/DERBY-1766 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.2.1.0 Environment: Any Reporter: Øystein Grøvlen Priority: Minor The test jdbcapi/batchUpdate.java is disabled in the DerbyNetClient framework. The reason seems to be that you get a general exception, BatchUpdateException, instead of the specific exceptions you get in the embedded framework. The fix for this is probably to unwrap the BatchUpdateException to get to the more specific exception. Since batchUpdate.java does not run in client/server, DERBY-1292 has added a test to derbynet/prepStmt.java that really belongs in batchUpdate. As part of fixing this JIRA, that test, and other similar tests in prepStmt, should be moved to batchUpdate. It also seems like parameterMapping.java had similar problems which was changed by changing the canon to expect BatchUpdateExceptions. In my opinion, one should also unwrap the BatchUpdateExceptions in that test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1767) insertRow(), updateRow() and deleteRow() cannot handle table names and column names containing double quotes
[ http://issues.apache.org/jira/browse/DERBY-1767?page=all ] Fernanda Pizzorno reassigned DERBY-1767: Assignee: Fernanda Pizzorno insertRow(), updateRow() and deleteRow() cannot handle table names and column names containing double quotes Key: DERBY-1767 URL: http://issues.apache.org/jira/browse/DERBY-1767 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.2.1 Reporter: Knut Anders Hatlen Assigned To: Fernanda Pizzorno Priority: Minor Attachments: QuotesInNames.java ResultSet.insertRow(), ResultSet.updateRow() and ResultSet.deleteRow() fail with syntax error if the table name or a column name contains a double quote character. The attached repro gives this stack trace: Exception in thread main java.sql.SQLSyntaxErrorException: Syntax error: Encountered quoted at line 1, column 24. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:137) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:72) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:203) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:380) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:345) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1378) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4342) at org.apache.derby.impl.jdbc.EmbedResultSet.insertRow(EmbedResultSet.java:3678) at QuotesInNames.main(QuotesInNames.java:15) Caused by: java.sql.SQLException: Syntax error: Encountered quoted at line 1, column 24. ... 11 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4
[ http://issues.apache.org/jira/browse/DERBY-1633?page=all ] Mike Matrigali updated DERBY-1633: -- Fix Version/s: 10.1.4.0 10.3.0.0 committed d1633_10_1_merge.patch to the 10.1 branch. m101_142:48svn commit Sendingjava\client\org\apache\derby\client\am\SectionManager.java Sending java\engine\org\apache\derby\impl\sql\compile\BinaryRelationalOperatorNode.java Sending java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java Sendingjava\engine\org\apache\derby\impl\sql\compile\OptimizerImpl.java Sendingjava\engine\org\apache\derby\impl\sql\compile\Predicate.java Sending java\engine\org\apache\derby\impl\sql\compile\ProjectRestrictNode.java Sending java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java Sendingjava\engine\org\apache\derby\impl\sql\compile\SelectNode.java Sending java\engine\org\apache\derby\impl\sql\compile\SetOperatorNode.java Sending java\testing\org\apache\derbyTesting\functionTests\master\predicatePushdown.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\predicatePushdown.sql Transmitting file data ... Committed revision 437718 Regression: The fields of views are not being calculated properly since 10.1.2.4 Key: DERBY-1633 URL: http://issues.apache.org/jira/browse/DERBY-1633 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.0, 10.1.3.1 Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory Reporter: Prasenjit Sarkar Assigned To: A B Fix For: 10.2.1.0, 10.3.0.0, 10.1.4.0 Attachments: d1633_10_1_merge.patch, d1633_repro.sql, d1633_v1_reviewOnly.patch, d1633_v2.patch, d1633_v3_code.patch, d1633_v3_tests.patch, DERBY-1633_v1.html, DERBY-1633_v2.html, DERBY-1633_v3.html Database can be assumed to be same as in Derby - 1205 Jira issue SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID This works fine in 10.1.2.1 but fails thereafter complaining that Comparison between INTEGER and CHAR is not supported for some reason, it thinks one of the PORT_ID columns is a character, when in reality both are integers. SELECT DISTINCT ZONE.ZONE_ID ZONE_ID, PORT2ZONE.ZONE_MEMBER_ID FROM T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE PORT2ZONE on ZONE.ZONE_ID = PORT2ZONE.ZONE_ID , T_RES_FABRIC FABRIC In this query, it is complaining that one of the columns is a VARCHAR and cannot be compared to INTEGER, when clearly this is not the case... Same issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1744) ResultSet.rowInserted(), rowUpdated() and rowDeleted() don't throw exception on read-only result sets
[ http://issues.apache.org/jira/browse/DERBY-1744?page=comments#action_12430986 ] Dag H. Wanvik commented on DERBY-1744: -- I raised this with Lance, and the JDBC Expert Group has now added the support optional wording to rowUpdated and rowInserted, as well. I.e. there is no longer a requirement that we throw exceptions for rowXXX methods in the case of read-only RS. Since support is now marked as optional in the API, we should add a note in the docs on how Derby behaves wrt this. I will file a JIRA. The API change should become apparent at http://download.java.net/jdk6/docs/api/ as soon as the next build is available (rc-b98). ResultSet.rowInserted(), rowUpdated() and rowDeleted() don't throw exception on read-only result sets - Key: DERBY-1744 URL: http://issues.apache.org/jira/browse/DERBY-1744 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.0.2.1 Reporter: Knut Anders Hatlen Assigned To: Knut Anders Hatlen Priority: Minor These methods should throw SQLException if concurrency is CONCUR_READ_ONLY. See http://download.java.net/jdk6/docs/api/java/sql/ResultSet.html: Throws: SQLException - if a database access error occurs; the result set concurrency is CONCUR_READ_ONLY or this method is called on a closed result set -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1769) Add mention that Derby supports rowUpdated, rowDeleted with a result set concurrency of CONCUR_READ_ONLY
Add mention that Derby supports rowUpdated, rowDeleted with a result set concurrency of CONCUR_READ_ONLY - Key: DERBY-1769 URL: http://issues.apache.org/jira/browse/DERBY-1769 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.2.1.0, 10.2.2.0, 10.3.0.0 Reporter: Dag H. Wanvik Priority: Minor Fix For: 10.3.0.0 We should add a note on the behavior on the rowXXX methods in java.sql.ResultSet, since they now (as of JDBC 4.0) have an optional feature. Cf this Note: for rowDeleted in JDBC4 API: boolean rowDeleted() throws SQLException Retrieves whether a row has been deleted. A deleted row may leave a visible hole in a result set. This method can be used to detect holes in a result set. The value returned depends on whether or not this ResultSet object can detect deletions. Note: Support for the rowDeleted method is optional with a result set concurrency of CONCUR_READ_ONLY Returns: true if the current row is detected to have been deleted by the owner or another; false otherwise Throws: SQLException - if a database access error occurs or this method is called on a closed result set SQLFeatureNotSupportedException - if the JDBC driver does not support this method Since: 1.2 See Also: DatabaseMetaData.deletesAreDetected(int) For updatable result sets, Derby supports calling the methods rowDeleted, rowUpdated and rowInserted even if the RS had concurrency CONCUR_READ_ONLY. If the query's underlying result set if scrollable and updatable, rowUpdated and rowDeleted can be used to detect if changes were made using positioned UPDATE/DELETEs, since positioned modifications are seen by the result set in Derby. Normally, though, such usage is not recommended. If updates are required, the RS should have concurrency CONCUR_UPDATABLE. rowInserted will always return false, since Derby does not detect inserts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Resolved: (DERBY-1533) ArrayIndexOutOfBoundsException in DDMReader, on a specific data size
I would like to close the bug, but I'm afraid I don;t have the privileges, so maybe you could do it yourself? Hi Wiktor, thanks for testing the fix! If you send a message to the derby-dev@db.apache.org mailing list, asking for developer access to JIRA, somebody will grant you the appropriate privileges to be able to close the bug in JIRA. And I have one question: do you plan any official release, with the fix of this bug, in the nearest future? This fix is in the 10.2 branch, and will be part of the upcoming 10.2 release. You can verify this by downloading the testing with the 10.2 beta release: http://wiki.apache.org/db-derby/TenTwoRelease thanks, bryan
[jira] Commented: (DERBY-1740) Change error message to indicate encryptionkey length to be atleast 16 characters instead of 8 characters
[ http://issues.apache.org/jira/browse/DERBY-1740?page=comments#action_12430991 ] Kristian Waagan commented on DERBY-1740: I think my previous comment is incorrect. Can anyone help my out here? It seems the concepts of 'bootPassword' and 'encryptionKey' are pretty much unrelated [in Derby]. If you create the database with a boot password, you must always boot the database with a boot password. You cannot specify a corresponding encryption key to boot it. The same goes for encryptionKey, you cannot boot it using a corresponding boot password. Is my understanding correct? Further, it seems code handling these two concepts are co-located in the same classes/methods, and often a single error message is used for error-situations for both concepts. For instance, if I create an encrypted database using the encryptionKey attribute and try to boot it using an incorrect encryptionKey, or by using the bootPassword attribute, I get: ERROR XBM06: Startup failed. An encrypted database cannot be accessed without the correct boot password. Also, specifying both attributes gives the same exception/SQLState as above. Thus it seems this Jira is only one of several related problems/inaccuracies related to creating/booting encrypted databases. Can anyone with more knowledge comment on this? Change error message to indicate encryptionkey length to be atleast 16 characters instead of 8 characters - Key: DERBY-1740 URL: http://issues.apache.org/jira/browse/DERBY-1740 Project: Derby Issue Type: Bug Affects Versions: 10.0.2.0 Environment: Any Reporter: Rajesh Kartha Priority: Minor Fix For: 10.2.1.0 Attachments: derby-1740-1a.diff While attempting to create a encrypted database with even key length of 14 characters, it fails with the error message indicating the key length should be atleast 8 characters. -- -- Attempt to encrypt using key of lenght 14 -- ij connect 'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=11223344556677'; ERROR XJ041: Failed to create database 'adb', see the next exception for details. ERROR XBM01: Startup failed due to an exception. See next exception for details. ERROR XBCX2: Initializing cipher with a boot password that is too short. The password must be at least 8 characters long. -- --Requires 16 characters for the encryptionKey -- ij connect 'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=1122334455667788'; ij -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset
The current interface to reopen a heap scan at the beginning
is reopenScan(), I think it is confusing to change
positionAtRowLocation(null) to also do this.
Does your usage want the table level intent lock released or not?
Because previously this code was never triggered by user code
the heap implmentation does the unlocking in the fetchRows
side which was always called immediately after the reopen. Now that
a user can indirectly cause a reopen and a fetch in separate statements
it is reasonable to move the release of the lock to the reopen rather
than delay it to the next fetch.
Note the reopenScan() logic the btree case already does the unlocking
here (code is completely different than heap case, so can't be copied).
To reposition a heap scan at the beginning you should just be able to
call:
reopenScan() with mostly null args, this is the standard way most heap
scans are positioned at the beginning.
Does your code use the reopenScanByRowLocation interfaces, I don't
think this code is doing unlocking in read committed correctly either.
/mikem
Andreas Korneliussen wrote:
Can you just close the scan if you don't need it positioned anymore?
I'll check if that works
The problem is that we need it re-positioned later, i.e if the user
moves to the afterLast() position and then scrolls to any other row, we
need to lock that row.
If the scan has been closed with close(), we cannot reopen it. If it has
been closed with closeForEndTransaction(.) we may reopen it, however
that would be quite undesirable, since we are not ending the
transaction, and we do not access the scancontroller from ScanManager
(which has closeForEndTransaction(.).
An alternative which I have considered is to make
ScanController.positionAtRowLocation(..) handle this by adding semantics
to the RowLocation being NULL.
I.e in HeapScan.java add this:
public boolean positionAtRowLocation(RowLocation rl) throws
StandardException {
if (rl==null)
{
positionAtDoneScan(scan_position);
return(false);
}
positionAtDoneScan will set the scan state to SCAN_DONE and release lock
as desired.
Andreas
for each row mode db2sql
In order to declare a Derby trigger, you need to include the phrase mode db2sql. I can't find this phrase in the ANSI SQL spec--trigger declaration is described in volume 2, section 11.39. The phrase does turn up in the DB2 reference manual, where it has this explanation: This clause is used to specify the mode of triggers. This is the only valid mode currently supported.. I would like to strike some happy balance between our goals of supporting ANSI syntax and maintaining compatibility with previous releases of Derby. Is there any reason that this phrase should not be made optional? Thanks, -Rick
[jira] Commented: (DERBY-1583) With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE
[ http://issues.apache.org/jira/browse/DERBY-1583?page=comments#action_12430997 ] Mamta A. Satoor commented on DERBY-1583: Bryan, looking at the stack track, it seems that we are trying to add a column privilege requirement in the execute phase of create trigger. When I had first encountered this NPE, I vaguely remember that this same colunm requirement was already added during the compile phase of the trigger and hence we might not need to add any privilege requiement at execute phase. I think you will have todo more research to see if theory is good. With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE -- Key: DERBY-1583 URL: http://issues.apache.org/jira/browse/DERBY-1583 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Reporter: Mamta A. Satoor Assigned To: Bryan Pendleton Fix For: 10.2.1.0 Attachments: setTableDescriptor.diff, setTableDescriptor.diff While working on SQL authorization work, I ran across a test case where Derby will throw a NPE when a trigger is defined with it's action as update a table from another schema. I don't have much details on why but following is the test case. Derby is trying to put privilege requirement for a column into privilege requirements list and it expects the column's tableUUID to be not null but in this particular case, it is null. connect 'jdbc:derby:c:/dellater/dbmain;create=true' user 'mamta1' as mamta1; create table t11TriggerRevokeTest (c111 int not null primary key, c12 int); grant TRIGGER on t11TriggerRevokeTest to mamta2; create table t12TriggerRevokeTest (c121 int, c122 int, c123 int); grant UPDATE(c122, c121) on t12TriggerRevokeTest to mamta2; connect 'jdbc:derby:c:/dellater/dbmain;create=true' user 'mamta2' as mamta2; create trigger tr11t11 after insert on mamta1.t11TriggerRevokeTest for each statement mode db2sql update mamta1.t12TriggerRevokeTest set c122 = 99; The stack trace looks as follows ij(MAMTA2) ERROR XJ001: Java exception: ': java.lang.NullPointerException'.java.lang.NullPointerException at org.apache.derby.impl.sql.compile.CompilerContextImpl.addRequiredColumnPriv(CompilerContextImpl.java:741) at org.apache.derby.impl.sql.compile.ResultColumn.bindResultColumnByName(ResultColumn.java:682) at org.apache.derby.impl.sql.compile.ResultColumnList.bindResultColumnsByName(ResultColumnList.java:635) at org.apache.derby.impl.sql.compile.ResultSetNode.bindResultColumns(ResultSetNode.java:682) at org.apache.derby.impl.sql.compile.SelectNode.bindResultColumns(SelectNode.java:751) at org.apache.derby.impl.sql.compile.UpdateNode.bind(UpdateNode.java:348) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:344) at org.apache.derby.impl.sql.GenericStatement.prepareStorable(GenericStatement.java:591) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(SPSDescriptor.java:353) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:283) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(CreateTriggerConstantAction.java:367) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(CreateTriggerConstantAction.java:272) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:357) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:207) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:173) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4
[ http://issues.apache.org/jira/browse/DERBY-1633?page=all ] A B resolved DERBY-1633. Fix Version/s: 10.1.3.2 (was: 10.1.4.0) Resolution: Fixed Derby Info: [Existing Application Impact, Regression] (was: [Patch Available, Existing Application Impact, Regression]) Many thanks to Rick and to Mike for porting this fix back to 10.2 and 10.1, respectively. I confirmed that the change is in 10.1 and als in the latest 10.2 beta snapshot. Also, the new test cases in lang/predicatePushdown.sql run correctly in both codelines. Since this fix is now in trunk, 10.2, and 10.1, I'm marking it resolved and clearing the patch available flag. Thanks also to Rick for taking the time to review the different iterations of this rather involved patch. I appreciate your time! Regression: The fields of views are not being calculated properly since 10.1.2.4 Key: DERBY-1633 URL: http://issues.apache.org/jira/browse/DERBY-1633 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.0, 10.1.3.1 Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory Reporter: Prasenjit Sarkar Assigned To: A B Fix For: 10.1.3.2, 10.2.1.0, 10.3.0.0 Attachments: d1633_10_1_merge.patch, d1633_repro.sql, d1633_v1_reviewOnly.patch, d1633_v2.patch, d1633_v3_code.patch, d1633_v3_tests.patch, DERBY-1633_v1.html, DERBY-1633_v2.html, DERBY-1633_v3.html Database can be assumed to be same as in Derby - 1205 Jira issue SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID This works fine in 10.1.2.1 but fails thereafter complaining that Comparison between INTEGER and CHAR is not supported for some reason, it thinks one of the PORT_ID columns is a character, when in reality both are integers. SELECT DISTINCT ZONE.ZONE_ID ZONE_ID, PORT2ZONE.ZONE_MEMBER_ID FROM T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE PORT2ZONE on ZONE.ZONE_ID = PORT2ZONE.ZONE_ID , T_RES_FABRIC FABRIC In this query, it is complaining that one of the columns is a VARCHAR and cannot be compared to INTEGER, when clearly this is not the case... Same issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1681) Regression (wrong results): Join predicate can be ignored for left-most child in a chain of nested unions.
[ http://issues.apache.org/jira/browse/DERBY-1681?page=comments#action_12431007 ] A B commented on DERBY-1681: Thanks for commiting the new test case to trunk and 10.2, Mike. Since the changes for DERBY-1633 have now been ported to 10.1 (thank you for that, too, Mike!), can the test case for this issue go to 10.1, as well? It should be a simple merge: svn merge -r 437379:437380 http://svn.apache.org/repos/asf/db/derby/code/trunk Also, one small note: it looks there's a typo in the Jira issue for the svn commit logs with the d1681_test_v2.patch: there are a couple of references to DERBY-1691 instead of DERBY-1681. Perhaps these can be corrected? Regression (wrong results): Join predicate can be ignored for left-most child in a chain of nested unions. -- Key: DERBY-1681 URL: http://issues.apache.org/jira/browse/DERBY-1681 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.1.3.0, 10.2.1.0 Reporter: A B Assigned To: A B Fix For: 10.2.1.0, 10.1.4.0 Attachments: d1681_test.patch, d1681_test_v2.patch, d1681_v1.patch, DERBY-1681_v1.html If Derby chooses to do a join between two FromTables and the right table is a chain of UNIONs, then the optimizer may choose to push the join predicate (if provided) down into the UNION and to both children of every UNION in the chain. But if the predicate cannot be pushed to the children of any of the UNIONs (except the top-level one) the predicate can end up being ignored altogether with respect to that UNION's children. The result is that query execution can return rows that do not satisfy the predicate. This is a regression introduced in 10.1.2.4 and thus it affects 10.1.3 and 10.2. I came across this while tracing through code for DERBY-1633. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api
[ http://issues.apache.org/jira/browse/DERBY-1417?page=all ] Kristian Waagan updated DERBY-1417: --- Attachment: derby-1417-9a-blobstream-newapproach.diff derby-1417-9a-blobstream-newapproach.stat Knut Anders, Your worries make sense. However, I think there is an easier solution. Since the only place that has to be changed to enable blob streaming is SQLBlob.setWidth, I have modified it accordingly. No changes are done to code elsewhere, and if getLength is called the stream will be materialized as before this patch. This can be handled as/if it is detected, and we might reconsider your solution. The new, and hopefully last patch, is 'derby-1417-9a-blobstream-newapproach.diff'. It implements a different approach and deprecates revision 8a. I also updated the single test that was failing to an incorrect SQL state in the test (see comment from 24/Aug/06 02:35 AM above). I ran derbyall with JDK 1.6, and the only test failing was TestQueryObject (awaiting bugfix in the JDK?). Thanks, Add new, lengthless overloads to the streaming api -- Key: DERBY-1417 URL: http://issues.apache.org/jira/browse/DERBY-1417 Project: Derby Issue Type: New Feature Components: JDBC Affects Versions: 10.2.1.0 Reporter: Rick Hillegas Assigned To: Kristian Waagan Fix For: 10.2.1.0 Attachments: derby-1417-01-castsInTests.diff, derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat, derby-1417-6b-clientimpl.diff, derby-1417-6c-clientimpl.diff, derby-1417-6d-clientimpl.diff, derby-1417-7a-clientborderfix.diff, derby-1417-7a-clientborderfix.stat, derby-1417-8a-enableblobstreaming.diff, derby-1417-8a-enableblobstreaming.stat, derby-1417-9a-blobstream-newapproach.diff, derby-1417-9a-blobstream-newapproach.stat The JDBC4 Expert Group has approved a new set of overloads for the streaming methods. These overloads do not take a length argument. Here are the new overloads: PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x) PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x) PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader reader) PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader reader) PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream) PreparedStatement.setClob(int parameterIndex, java.io.Reader reader) PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader) CallableStatement.setAsciiStream(java.lang.String parameterName, java.io.InputStream x) CallableStatement.setBinaryStream(java.lang.String parameterName, java.io.InputStream x) CallableStatement.setCharacterStream(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setNCharacterStream(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream inputStream) CallableStatement.setClob(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader reader) ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x) ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream x) ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x) ResultSet.updateBinaryStream(java.lang.String columnLabel, java.io.InputStream x, int length) ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x) ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader x) ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x) ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader x) ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream) ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream inputStream) ResultSet.updateClob(int columnIndex, java.io.Reader reader) ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader) ResultSet.updateNClob(int columnIndex, java.io.Reader reader) ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader) We should add these new overloads soon so that the build will not break when this methods turn up in a published Mustang build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Closed: (DERBY-1744) ResultSet.rowInserted(), rowUpdated() and rowDeleted() don't throw exception on read-only result sets
[ http://issues.apache.org/jira/browse/DERBY-1744?page=all ] Knut Anders Hatlen closed DERBY-1744. - Resolution: Invalid Thanks to Dag and Lance for clearing this up. Closing the issue as invalid. ResultSet.rowInserted(), rowUpdated() and rowDeleted() don't throw exception on read-only result sets - Key: DERBY-1744 URL: http://issues.apache.org/jira/browse/DERBY-1744 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.0.2.1 Reporter: Knut Anders Hatlen Assigned To: Knut Anders Hatlen Priority: Minor These methods should throw SQLException if concurrency is CONCUR_READ_ONLY. See http://download.java.net/jdk6/docs/api/java/sql/ResultSet.html: Throws: SQLException - if a database access error occurs; the result set concurrency is CONCUR_READ_ONLY or this method is called on a closed result set -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1768) Remove JDBC 4.0 RowId classes
[ http://issues.apache.org/jira/browse/DERBY-1768?page=comments#action_12431020 ] Daniel John Debrunner commented on DERBY-1768: -- Could the classes be left in the codeline and just excluded by the build? Do they even show up in the jar files? I would have thought not for embedded and I thought the client moved to a dependency build. Remove JDBC 4.0 RowId classes - Key: DERBY-1768 URL: http://issues.apache.org/jira/browse/DERBY-1768 Project: Derby Issue Type: Improvement Affects Versions: 10.2.1.0 Reporter: Knut Anders Hatlen Assigned To: Knut Anders Hatlen Priority: Minor Attachments: rowid.diff, rowid.stat JDBC 4.0 introduced the java.sql.RowId interface. Derby has implemented this interface both in the client driver and the embedded driver, but the methods only throw java.lang.UnsupportedOperationException, and an application has no way to get a RowId object. To reduce the footprint, these unused classes should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: for each row mode db2sql
Rick Hillegas wrote: In order to declare a Derby trigger, you need to include the phrase mode db2sql. I can't find this phrase in the ANSI SQL spec--trigger declaration is described in volume 2, section 11.39. The phrase does turn up in the DB2 reference manual, where it has this explanation: This clause is used to specify the mode of triggers. This is the only valid mode currently supported.. I would like to strike some happy balance between our goals of supporting ANSI syntax and maintaining compatibility with previous releases of Derby. Is there any reason that this phrase should not be made optional? +1 Since Derby triggers are (or strive to be...) standard compliant, the mode db2sql should be optional. I was thinking of creating a Jira issue of this one myself. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
[jira] Commented: (DERBY-606) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
[
http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12431025 ]
Sunitha Kambhampati commented on DERBY-606:
---
I can reproduce this failure in one of my test scenarios on a very large table:
ij call syscs_util.syscs_inplace_compress_table('APP','STOCK',1,1,1);
ERROR XSLB1: Log operation null encounters error writing itself out to the log
stream, this could be caused by an errant log operation or internal log buffer
full due to excessively large log operation.
ERROR XJ001: Java exception: ': java.io.IOException'.
stock has 60million rows.
schema for stock table.
ij create table stock (
s_i_id int NOT NULL,
s_w_id smallint NOT NULL,
s_quantity int NOT NULL,
s_dist_01 char(24) NOT NULL,
s_dist_02 char(24) NOT NULL,
s_dist_03 char(24) NOT NULL,
s_dist_04 char(24) NOT NULL,
s_dist_05 char(24) NOT NULL,
s_dist_06 char(24) NOT NULL,
s_dist_07 char(24) NOT NULL,
s_dist_08 char(24) NOT NULL,
s_dist_09 char(24) NOT NULL,
s_dist_10 char(24) NOT NULL,
s_ytd decimal(8) NOT NULL,
s_order_cnt int NOT NULL,
s_remote_cntint NOT NULL,
s_data varchar(50) NOT NULL
);
There is no error messages in derby.log. I'll try to rerun the test and run
with ij.execptionTrace=true to get the entire trace.
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
Key: DERBY-606
URL: http://issues.apache.org/jira/browse/DERBY-606
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.1.0
Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition
Reporter: Jeffrey Aguilera
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails with one of the following error
messages when applied to a very large table (2GB):
Log operation null encounters error writing itself out to the log stream,
this could be caused by an errant log operation or internal log buffer full
due to excessively large log operation. SQLSTATE: XJ001: Java exception: ':
java.io.IOException'.
or
The exception 'java.lang.ArrayIndexOutOfBoundsException' was thrown while
evaluating an expression. SQLSTATE: XJ001: Java exception: ':
java.lang.ArrayIndexOutOfBoundsException'.
In either case, no entry is written to the console log or to derby.log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1768) Remove JDBC 4.0 RowId classes
[ http://issues.apache.org/jira/browse/DERBY-1768?page=comments#action_12431023 ] Knut Anders Hatlen commented on DERBY-1768: --- EmbedRowId is in derby.jar because RowIdNotImplementedTest and Driver40 have a direct reference to it. The client class is not in derbyclient.jar. Since the classes have no functionality at all, I don't see much point in leaving them in the codeline. You could always restore them from subversion later. Remove JDBC 4.0 RowId classes - Key: DERBY-1768 URL: http://issues.apache.org/jira/browse/DERBY-1768 Project: Derby Issue Type: Improvement Affects Versions: 10.2.1.0 Reporter: Knut Anders Hatlen Assigned To: Knut Anders Hatlen Priority: Minor Attachments: rowid.diff, rowid.stat JDBC 4.0 introduced the java.sql.RowId interface. Derby has implemented this interface both in the client driver and the embedded driver, but the methods only throw java.lang.UnsupportedOperationException, and an application has no way to get a RowId object. To reduce the footprint, these unused classes should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1686) Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail
[ http://issues.apache.org/jira/browse/DERBY-1686?page=comments#action_12431026 ] Mamta A. Satoor commented on DERBY-1686: Yip, I am still looking through the patch but have a question after a quick look at the patch. In new method bindPrivilegesForView() in TablePrivilegesNode.java, I noticed that we check if the current user is the database owner and if yes, then we do not build the provider list for the views. Is this happening at compile time? If yes, then it might not be correct. I think, at compile time, we want to build the provider list no matter who is compiling the statement. It is at run time that we want to disregard provider list if the database owner is granting the privilege. This is because, database owner might be the one to compile the statement first. But the view owner (assume that is not same as database owner) might execute the same statement later, but if we do not have the provider list attached to the statement plan created by database owner, then at execution time by view owner, we will not catach provider objects which are not owner by the view owner. Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail --- Key: DERBY-1686 URL: http://issues.apache.org/jira/browse/DERBY-1686 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Any Reporter: Rajesh Kartha Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1686-trunk-diff01.txt, derby1686-trunk-diff02.txt, derby1686-trunk-stat01.txt, derby1686-trunk-stat02.txt, select_table_no_privilege.sql With authentication on, attempting to execute a GRANT privilege to 'user3' on a VIEW created by the 'user2' - who has only SELECT privilege on the base table created by 'user1' does not fail. This results in 'user3' getting access to the table created by 'user1' through the view. I remember a discussion on the list to raise an error when an attempt is execute a GRANT on the view, until WITH GRANT option is implemented. Here is the repro: java -cp derby.jar;.\derbytools.jar -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij select_table_no_privilege.sql ij version 10.2 ij -- --create db as user1 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1(id int); 0 rows inserted/updated/deleted ij insert into t1 values(100); 1 row inserted/updated/deleted ij insert into t1 values(200); 1 row inserted/updated/deleted ij -- --Grant select to user2 -- grant select on t1 to user2; 0 rows inserted/updated/deleted ij -- --Connect as user2 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user2'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existingdatabase instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION1) select * from user1.t1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Create view -- create view v1 as select * from user1.t1; 0 rows inserted/updated/deleted ij(CONNECTION1) select * from v1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Grant select on view to user3. With the WITH GRANT option this should have failed -- grant select on v1 to user3; 0 rows inserted/updated/deleted ij(CONNECTION1) -- --Connect as user3 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user3'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION2) -- --No select privilege on base table user1.t1, hence will FAIL -- select * from user1.t1; ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(Unknown Source) at org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.fillResultSet(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.execute(Unknown Source) at
[jira] Commented: (DERBY-1746) upgrade tests should start using 10.1.3 released builds
[ http://issues.apache.org/jira/browse/DERBY-1746?page=comments#action_12431034 ] Myrna van Lunteren commented on DERBY-1746: --- I experimented and found the following: - the problem appears to be with 10.1.3.1 derby.jar. Using the other 10.1.3.1 jars don't cause the same trouble. - comparing the 10.1.1.0 derby.jar and 10.1.3.1 derby.jar it seemed the main difference was that the 10.1.3.1. does not have the directories in the jar. - When I unjarred 10.1.3.1 derby.jar with jar -tvf, and then jar-ed back up using jar -xvf *, the resulting derby.jar could be used the test did not give the sealing error. This is very strange, does this mean the 10.1.3.1 jars are bad? I welcome any suggestions on how to proceed. upgrade tests should start using 10.1.3 released builds --- Key: DERBY-1746 URL: http://issues.apache.org/jira/browse/DERBY-1746 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.2.1.0 Reporter: Myrna van Lunteren Assigned To: Myrna van Lunteren Priority: Minor Fix For: 10.2.1.0 Attachments: DERBY-1746_102_20060823.diff, DERBY-1746_102_20060823.stat, DERBY-1746_trunk_20060824.diff The upgrade test' master is based on the 10.1 jars checked in to svn - 10.1.1.0 - (208786). However, we now have a newer released version of 10.1 - 10.1.3. This would be the obvious choice for someone running tests testing the beta jars. If the jars are 10.1.3 then a diff will occur because of the fix for DERBY-655: 703d702 ,APP,DERBY655T2,C21_ID,,APP,DERBY655T1,C11_ID,1,3,0,F_12,GENERATED-ID, 7 2168d2166 ,APP,DERBY655T2,C21_ID,,APP,DERBY655T1,C11_ID,1,3,0,F_12,GENERATED-ID, 7 It would be nice if the final build for 10.2 would include an updgrade test master created using 10.1.3, And same is true for the trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1746) upgrade tests should start using 10.1.3 released builds
[ http://issues.apache.org/jira/browse/DERBY-1746?page=comments#action_12431037 ] Myrna van Lunteren commented on DERBY-1746: --- For the record, this is the 'full' stack trace from the .tmp file (no derby.log appears to get created) START - phase CREATE java.lang.ExceptionInInitializerError at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.getConnectionUsingDataSource(UpgradeTester.java:461) at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.getConnection(UpgradeTester.java:418) at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.runPhase(UpgradeTester.java:357) at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.runUpgradeTests(UpgradeTester.java:317) at org.apache.derbyTesting.functionTests.tests.upgradeTests.Upgrade_10_1_10_2.main(Upgrade_10_1_10_2.java:44) Caused by: java.lang.SecurityException: sealing violation: can't seal package org.apache.derby.iapi.services.crypto: already loaded at java.net.URLClassLoader.defineClass(URLClassLoader.java:234) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.derby.impl.services.monitor.BaseMonitor.getImplementations(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.getDefaultImplementations(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown Source) at org.apache.derby.impl.services.monitor.FileMonitor.init(Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown Source) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.clinit(Unknown Source) ... 8 more Exception in thread main upgrade tests should start using 10.1.3 released builds --- Key: DERBY-1746 URL: http://issues.apache.org/jira/browse/DERBY-1746 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.2.1.0 Reporter: Myrna van Lunteren Assigned To: Myrna van Lunteren Priority: Minor Fix For: 10.2.1.0 Attachments: DERBY-1746_102_20060823.diff, DERBY-1746_102_20060823.stat, DERBY-1746_trunk_20060824.diff The upgrade test' master is based on the 10.1 jars checked in to svn - 10.1.1.0 - (208786). However, we now have a newer released version of 10.1 - 10.1.3. This would be the obvious choice for someone running tests testing the beta jars. If the jars are 10.1.3 then a diff will occur because of the fix for DERBY-655: 703d702 ,APP,DERBY655T2,C21_ID,,APP,DERBY655T1,C11_ID,1,3,0,F_12,GENERATED-ID, 7 2168d2166 ,APP,DERBY655T2,C21_ID,,APP,DERBY655T1,C11_ID,1,3,0,F_12,GENERATED-ID, 7 It would be nice if the final build for 10.2 would include an updgrade test master created using 10.1.3, And same is true for the trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.
[ http://issues.apache.org/jira/browse/DERBY-883?page=all ] Daniel John Debrunner updated DERBY-883: Fix Version/s: 10.3.0.0 (was: 10.2.1.0) Change was commited to trunk (10.3) Enhance GROUP BY clause to support expressions instead of just column references. - Key: DERBY-883 URL: http://issues.apache.org/jira/browse/DERBY-883 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.1.2.1, 10.2.1.0 Environment: JDK 1.5.0_05 Reporter: Lluis Turro Assigned To: Manish Khettry Fix For: 10.3.0.0 Attachments: 883.patch.txt, 883.patch3.txt, 883.patch4.txt, 883.patch5.txt, 883.patch6.txt, 883.patch6.txt, 883.patch7.txt This select would return an error syntax on finding ( after month if group by clause: select idissue, month(creation), year(creation), count(distinct idissue) where group by idissue, month(creation), year(creation) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1130) Client should not allow databaseName to be set with setConnectionAttributes
[ http://issues.apache.org/jira/browse/DERBY-1130?page=all ]
Mike Matrigali updated DERBY-1130:
--
Derby Info: [Patch Available, Existing Application Impact, Release Note
Needed] (was: [Patch Available, Release Note Needed, Existing Application
Impact])
thanks for the review david, I'll run the tests and commit if they pass. If
anyone else is going to review let me know.
Client should not allow databaseName to be set with setConnectionAttributes
---
Key: DERBY-1130
URL: http://issues.apache.org/jira/browse/DERBY-1130
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1,
10.1.2.2, 10.1.2.3, 10.2.1.0, 10.1.3.0, 10.1.2.4
Reporter: Kathey Marsden
Assigned To: Deepa Remesh
Fix For: 10.2.1.0
Attachments: d1130-client-v1.diff, d1130-client-v1.status,
d1130-test-dataSourceReference.diff, d1130-test-dataSourceReference.status,
d1130-v2.diff, d1130-v2.status, derby-1130-v1.diff, derby-1130-v1.status
Per this thread, setConnectionAttributes should not set databaseName.
http://www.nabble.com/double-check-on-checkDataSource-t1187602.html#a3128621
Currently this is allowed for client but should be disabled. I think it is
OK to change because we have documented that client will be changed to match
embedded for implementation defined behaviour. Hopefully its use is rare as
most folks would use the standard setDatabaseName. Still there should be a
release not when the change is made and it would be better to change it
sooner than later:
Below is the repro.
Here is the output with Client
Djava DatabaseNameWithSetConnAttr
ds.setConnectionAttributes(databaseName=wombat;create=true)
ds.getDatabaseName() = null (should be null)
FAIL: Should not have been able to set databaseName with connection attributes
Also look for tests disabled with this bug number in the test
checkDataSource30.java
import java.sql.*;
import java.lang.reflect.Method;
public class DatabaseNameWithSetConnAttr{
public static void main(String[] args) {
try {
String attributes = databaseName=wombat;create=true;
org.apache.derby.jdbc.ClientDataSource ds = new
org.apache.derby.jdbc.ClientDataSource();
//org.apache.derby.jdbc.EmbeddedDataSource ds = new
//org.apache.derby.jdbc.EmbeddedDataSource();
System.out.println(ds.setConnectionAttributes( +
attributes + ));
ds.setConnectionAttributes(attributes);
System.out.println(ds.getDatabaseName() = +
ds.getDatabaseName()
+ (should be null) );
Connection conn = ds.getConnection();
} catch (SQLException e) {
String sqlState = e.getSQLState();
if (sqlState != null
sqlState.equals(XJ041))
{
System.out.println(PASS: An exception was
thrown trying to get a connetion from a datasource after setting databaseName
with setConnectionAttributes);
System.out.println(EXPECTED EXCEPTION: +
e.getSQLState()
+
- + e.getMessage());
return;
}
while (e != null)
{
System.out.println(FAIL - UNEXPECTED
EXCEPTION: + e.getSQLState());
e.printStackTrace();
e = e.getNextException();
}
return;
}
System.out.println(FAIL: Should not have been able to set
databaseName with connection attributes);
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
Øystein Grøvlen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1292?page=comments#action_12431049 ] Øystein Grøvlen commented on DERBY-1292: I have reviewed the new version of the patch and the code looks fine (except for the minor issue of lines longer than 80 characters). I have checked that it is fixes the bug, and also that it fixes the problem in the reproduction case for the duplicate bug report, DERBY-1321. derbyall also ran without errors for this patch. I recommend that a committer commits this patch. If you wnat this patch to be included in the upcoming 10.2 version, you will need to lobby the release manager in order to get it ported to the 10.2 branch. Doesn't have to be the release manager, any committer can merge a fix into 10.2, and any contributor can ease the passage by performing the merge and testing it to provide the merge command or a new patch. Dan.
[jira] Closed: (DERBY-1609) Add a runScript method to ij that takes a script as an InputStream and returns the output to a stream.
[ http://issues.apache.org/jira/browse/DERBY-1609?page=all ] Daniel John Debrunner closed DERBY-1609. Add a runScript method to ij that takes a script as an InputStream and returns the output to a stream. -- Key: DERBY-1609 URL: http://issues.apache.org/jira/browse/DERBY-1609 Project: Derby Issue Type: Improvement Components: Tools Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Priority: Minor Fix For: 10.2.1.0, 10.3.0.0 Useful for running ij SQL scripts as part of JUnit tests and for applications to use instead of the awkward way to use ij from a program today. /** * Run a SQL script from an input stream and write * the resulting output to the provided OutputStream. * * @param conn Connection to be used as the script's default connection. * @param sqlIn InputStream for the script. * @param inputEncoding Encoding of the script. * @param sqlOut OutputStream for the script's output * @param outputEncoding Output encoding to use. * @return Number of SQLExceptions thrown during the execution, -1 if not known. * @throws UnsupportedEncodingException */ public static int runScript( Connection conn, InputStream sqlIn, String inputEncoding, PrintStream sqlOut, String outputEncoding) throws UnsupportedEncodingException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4
[ http://issues.apache.org/jira/browse/DERBY-1633?page=comments#action_12431066 ] Prasenjit Sarkar commented on DERBY-1633: - I dont think this issue is resolved yet: I got a SQL error (same as above) for the following query that works in 10.1.2.1: SELECT HOST2FABRIC1.FABRIC_ID, HOST2FABRIC1.PREFIX_ID, HOST2FABRIC1.HOST_ID FROM T_VIEW_HOST2FABRIC HOST2FABRIC1, T_VIEW_HOST2FABRIC HOST2FABRIC2 WHERE HOST2FABRIC1.PREFIX_ID = HOST2FABRIC2.HOST_ID AND HOST2FABRIC1.HOST_ID = HOST2FABRIC2.HOST_ID AND HOST2FABRIC2.FABRIC_ID = ? Regression: The fields of views are not being calculated properly since 10.1.2.4 Key: DERBY-1633 URL: http://issues.apache.org/jira/browse/DERBY-1633 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.0, 10.1.3.1 Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory Reporter: Prasenjit Sarkar Assigned To: A B Fix For: 10.2.1.0, 10.3.0.0, 10.1.3.2 Attachments: d1633_10_1_merge.patch, d1633_repro.sql, d1633_v1_reviewOnly.patch, d1633_v2.patch, d1633_v3_code.patch, d1633_v3_tests.patch, DERBY-1633_v1.html, DERBY-1633_v2.html, DERBY-1633_v3.html Database can be assumed to be same as in Derby - 1205 Jira issue SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID This works fine in 10.1.2.1 but fails thereafter complaining that Comparison between INTEGER and CHAR is not supported for some reason, it thinks one of the PORT_ID columns is a character, when in reality both are integers. SELECT DISTINCT ZONE.ZONE_ID ZONE_ID, PORT2ZONE.ZONE_MEMBER_ID FROM T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE PORT2ZONE on ZONE.ZONE_ID = PORT2ZONE.ZONE_ID , T_RES_FABRIC FABRIC In this query, it is complaining that one of the columns is a VARCHAR and cannot be compared to INTEGER, when clearly this is not the case... Same issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1575) document full syntax of CASE expression
[ http://issues.apache.org/jira/browse/DERBY-1575?page=comments#action_12431067 ] Kim Haase commented on DERBY-1575: -- This issue is marked as major, and it looks like a relatively simple fix. I can take it on. document full syntax of CASE expression --- Key: DERBY-1575 URL: http://issues.apache.org/jira/browse/DERBY-1575 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Christian d'Heureuse The documentation at http://db.apache.org/derby/docs/dev/ref/rrefcasenullif.html describes the CASE expression syntax as: CASE WHEN BooleanExpression THEN thenExpression ELSE elseExpression END But the CASE expression supports more than one WHEN/THEN clauses. I suggest to change the syntax description to: CASE WHEN BooleanExpression THEN Expression [ WHEN BooleanExpression THEN Expression ] ... ELSE elseExpression END Example: VALUES CASE WHEN 1 = 2 THEN 3 WHEN 4 = 5 THEN 6 ELSE 7 END -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1575) document full syntax of CASE expression
[ http://issues.apache.org/jira/browse/DERBY-1575?page=all ] Kim Haase reassigned DERBY-1575: Assignee: Kim Haase document full syntax of CASE expression --- Key: DERBY-1575 URL: http://issues.apache.org/jira/browse/DERBY-1575 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Christian d'Heureuse Assigned To: Kim Haase The documentation at http://db.apache.org/derby/docs/dev/ref/rrefcasenullif.html describes the CASE expression syntax as: CASE WHEN BooleanExpression THEN thenExpression ELSE elseExpression END But the CASE expression supports more than one WHEN/THEN clauses. I suggest to change the syntax description to: CASE WHEN BooleanExpression THEN Expression [ WHEN BooleanExpression THEN Expression ] ... ELSE elseExpression END Example: VALUES CASE WHEN 1 = 2 THEN 3 WHEN 4 = 5 THEN 6 ELSE 7 END -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1686) Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail
[ http://issues.apache.org/jira/browse/DERBY-1686?page=comments#action_12431068 ] Yip Ng commented on DERBY-1686: --- Mamta, are you referring to the statement cache? I thought there is a statement cache per connection. So the DBA and the schema owner will have their own respective connection and hence won't be sharing the prepared grant statement. Or am I missing something? Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail --- Key: DERBY-1686 URL: http://issues.apache.org/jira/browse/DERBY-1686 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Any Reporter: Rajesh Kartha Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1686-trunk-diff01.txt, derby1686-trunk-diff02.txt, derby1686-trunk-stat01.txt, derby1686-trunk-stat02.txt, select_table_no_privilege.sql With authentication on, attempting to execute a GRANT privilege to 'user3' on a VIEW created by the 'user2' - who has only SELECT privilege on the base table created by 'user1' does not fail. This results in 'user3' getting access to the table created by 'user1' through the view. I remember a discussion on the list to raise an error when an attempt is execute a GRANT on the view, until WITH GRANT option is implemented. Here is the repro: java -cp derby.jar;.\derbytools.jar -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij select_table_no_privilege.sql ij version 10.2 ij -- --create db as user1 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1(id int); 0 rows inserted/updated/deleted ij insert into t1 values(100); 1 row inserted/updated/deleted ij insert into t1 values(200); 1 row inserted/updated/deleted ij -- --Grant select to user2 -- grant select on t1 to user2; 0 rows inserted/updated/deleted ij -- --Connect as user2 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user2'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existingdatabase instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION1) select * from user1.t1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Create view -- create view v1 as select * from user1.t1; 0 rows inserted/updated/deleted ij(CONNECTION1) select * from v1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Grant select on view to user3. With the WITH GRANT option this should have failed -- grant select on v1 to user3; 0 rows inserted/updated/deleted ij(CONNECTION1) -- --Connect as user3 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user3'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION2) -- --No select privilege on base table user1.t1, hence will FAIL -- select * from user1.t1; ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(Unknown Source) at org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.fillResultSet(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at
[jira] Commented: (DERBY-1555) API for configuration information in Derby's JUnit tests should through instance methods of the base classes, not static methods and static fields
[ http://issues.apache.org/jira/browse/DERBY-1555?page=comments#action_12431069 ] Daniel John Debrunner commented on DERBY-1555: -- Patch derby-1555-removecomment.diff Committed revision 437832 - Thanks Kristian API for configuration information in Derby's JUnit tests should through instance methods of the base classes, not static methods and static fields -- Key: DERBY-1555 URL: http://issues.apache.org/jira/browse/DERBY-1555 Project: Derby Issue Type: Improvement Components: Test Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Attachments: derby-1555-removecomment.diff The heavy use of static state information in the existing Derby (non-Junit) harness was a major mistake, it should not be repeated in the Junit model. It should be changed before too many tests are written. A static configuration will limit the ability for the tests to be flexible and have different instances running with different configurations, a instance based scheme will be more flexible. This change will just change the api, the current implementation of a single static configuration will remain but be hidden within the base-classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4
[ http://issues.apache.org/jira/browse/DERBY-1633?page=comments#action_12431073 ] A B commented on DERBY-1633: Thanks for continuing to test this particular fix, Prasenjit. I assume the query in the above comment is supposed to be run agains the same database that's in DERBY-1205? When I try to run it I see: prepare qFail as ' SELECT HOST2FABRIC1.FABRIC_ID, HOST2FABRIC1.PREFIX_ID, HOST2FABRIC1.HOST_ID FROM T_VIEW_HOST2FABRIC HOST2FABRIC1, T_VIEW_HOST2FABRIC HOST2FABRIC2 WHERE HOST2FABRIC1.PREFIX_ID = HOST2FABRIC2.HOST_ID AND HOST2FABRIC1.HOST_ID = HOST2FABRIC2.HOST_ID AND HOST2FABRIC2.FABRIC_ID = ? '; ERROR 42X04: Column 'HOST2FABRIC1.PREFIX_ID' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVIN G clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'HOST2FABRIC1.PREFIX_ID' is not a column in the target table. I also see this error when running against 10.1.2. So I'm wondering if this is actually the query you intended to post? Could you double-check and post the exact query that's causing the failure? Thanks. Regression: The fields of views are not being calculated properly since 10.1.2.4 Key: DERBY-1633 URL: http://issues.apache.org/jira/browse/DERBY-1633 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.0, 10.1.3.1 Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory Reporter: Prasenjit Sarkar Assigned To: A B Fix For: 10.2.1.0, 10.3.0.0, 10.1.3.2 Attachments: d1633_10_1_merge.patch, d1633_repro.sql, d1633_v1_reviewOnly.patch, d1633_v2.patch, d1633_v3_code.patch, d1633_v3_tests.patch, DERBY-1633_v1.html, DERBY-1633_v2.html, DERBY-1633_v3.html Database can be assumed to be same as in Derby - 1205 Jira issue SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID This works fine in 10.1.2.1 but fails thereafter complaining that Comparison between INTEGER and CHAR is not supported for some reason, it thinks one of the PORT_ID columns is a character, when in reality both are integers. SELECT DISTINCT ZONE.ZONE_ID ZONE_ID, PORT2ZONE.ZONE_MEMBER_ID FROM T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE PORT2ZONE on ZONE.ZONE_ID = PORT2ZONE.ZONE_ID , T_RES_FABRIC FABRIC In this query, it is complaining that one of the columns is a VARCHAR and cannot be compared to INTEGER, when clearly this is not the case... Same issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1746) upgrade tests should start using 10.1.3 released builds
Myrna van Lunteren (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1746?page=comments#action_12431034 ] Myrna van Lunteren commented on DERBY-1746: --- I experimented and found the following: - the problem appears to be with 10.1.3.1 derby.jar. Using the other 10.1.3.1 jars don't cause the same trouble. - comparing the 10.1.1.0 derby.jar and 10.1.3.1 derby.jar it seemed the main difference was that the 10.1.3.1. does not have the directories in the jar. - When I unjarred 10.1.3.1 derby.jar with jar -tvf, and then jar-ed back up using jar -xvf *, the resulting derby.jar could be used the test did not give the sealing error. Hi Myrna, This is just a shot in the dark, I have not investigated on my own. You say that you unjarred 10.1.3.1, then jar-ed the files back up. By looking at the jar command used, a manifest does not seem to be specified. Could the reason why the re-packaged jar is working be because it simply isn't sealed, as I suppose the official 10.1.3.1 jars are? -- Kristian This is very strange, does this mean the 10.1.3.1 jars are bad? I welcome any suggestions on how to proceed. upgrade tests should start using 10.1.3 released builds --- Key: DERBY-1746 URL: http://issues.apache.org/jira/browse/DERBY-1746 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.2.1.0 Reporter: Myrna van Lunteren Assigned To: Myrna van Lunteren Priority: Minor Fix For: 10.2.1.0 Attachments: DERBY-1746_102_20060823.diff, DERBY-1746_102_20060823.stat, DERBY-1746_trunk_20060824.diff The upgrade test' master is based on the 10.1 jars checked in to svn - 10.1.1.0 - (208786). However, we now have a newer released version of 10.1 - 10.1.3. This would be the obvious choice for someone running tests testing the beta jars. If the jars are 10.1.3 then a diff will occur because of the fix for DERBY-655: 703d702 ,APP,DERBY655T2,C21_ID,,APP,DERBY655T1,C11_ID,1,3,0,F_12,GENERATED-ID, 7 2168d2166 ,APP,DERBY655T2,C21_ID,,APP,DERBY655T1,C11_ID,1,3,0,F_12,GENERATED-ID, 7 It would be nice if the final build for 10.2 would include an updgrade test master created using 10.1.3, And same is true for the trunk.
Re: [jira] Commented: (DERBY-1746) upgrade tests should start using 10.1.3 released builds
On 8/28/06, Kristian Waagan [EMAIL PROTECTED] wrote: Myrna van Lunteren (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1746?page=comments#action_12431034 ] Myrna van Lunteren commented on DERBY-1746: --- I experimented and found the following: - the problem appears to be with 10.1.3.1 derby.jar. Using the other 10.1.3.1 jars don't cause the same trouble. - comparing the 10.1.1.0 derby.jar and 10.1.3.1 derby.jar it seemed the main difference was that the 10.1.3.1. does not have the directories in the jar. - When I unjarred 10.1.3.1 derby.jar with jar -tvf, and then jar-ed back up using jar -xvf *, the resulting derby.jar could be used the test did not give the sealing error. Hi Myrna, This is just a shot in the dark, I have not investigated on my own. You say that you unjarred 10.1.3.1, then jar-ed the files back up. By looking at the jar command used, a manifest does not seem to be specified. Could the reason why the re-packaged jar is working be because it simply isn't sealed, as I suppose the official 10.1.3.1 jars are? -- Kristian I thought about that, but I assumed that if I unjarred a jar file that has a manifest (as the original 10.1.3.1 derby.jar has) this manifest also got unjarred, and thus, when jarring it back up, the manifest would get jarred back up also... Naive, probably...But the jar does contain the a manifest again. I'll see if poking at that gives me some clues. Myrna
[jira] Commented: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4
[ http://issues.apache.org/jira/browse/DERBY-1633?page=comments#action_12431091 ] A B commented on DERBY-1633: Does the above query work if you run it against Derby embedded instead of client/server? If it works in embedded but not with client/server, then I think this should be filed as a separate issue (against client or server; not sure which). If it fails to execute in embedded mode, too, then please post the stack trace here and we can use that to determine if the failure is related to this issue or if it needs its own Jira. Regression: The fields of views are not being calculated properly since 10.1.2.4 Key: DERBY-1633 URL: http://issues.apache.org/jira/browse/DERBY-1633 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.0, 10.1.3.1 Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory Reporter: Prasenjit Sarkar Assigned To: A B Fix For: 10.2.1.0, 10.3.0.0, 10.1.3.2 Attachments: d1633_10_1_merge.patch, d1633_repro.sql, d1633_v1_reviewOnly.patch, d1633_v2.patch, d1633_v3_code.patch, d1633_v3_tests.patch, DERBY-1633_v1.html, DERBY-1633_v2.html, DERBY-1633_v3.html Database can be assumed to be same as in Derby - 1205 Jira issue SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID This works fine in 10.1.2.1 but fails thereafter complaining that Comparison between INTEGER and CHAR is not supported for some reason, it thinks one of the PORT_ID columns is a character, when in reality both are integers. SELECT DISTINCT ZONE.ZONE_ID ZONE_ID, PORT2ZONE.ZONE_MEMBER_ID FROM T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE PORT2ZONE on ZONE.ZONE_ID = PORT2ZONE.ZONE_ID , T_RES_FABRIC FABRIC In this query, it is complaining that one of the columns is a VARCHAR and cannot be compared to INTEGER, when clearly this is not the case... Same issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1686) Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail
[ http://issues.apache.org/jira/browse/DERBY-1686?page=comments#action_12431095 ] Yip Ng commented on DERBY-1686: --- Hmm... I probably should not make any assumptions for the equals method since it could changed in the future and not rely on the compilation schema. I'll remove the dba check at compilation time and resubmit the patch. Thanks for your comment, Mamta. Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail --- Key: DERBY-1686 URL: http://issues.apache.org/jira/browse/DERBY-1686 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Any Reporter: Rajesh Kartha Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1686-trunk-diff01.txt, derby1686-trunk-diff02.txt, derby1686-trunk-stat01.txt, derby1686-trunk-stat02.txt, select_table_no_privilege.sql With authentication on, attempting to execute a GRANT privilege to 'user3' on a VIEW created by the 'user2' - who has only SELECT privilege on the base table created by 'user1' does not fail. This results in 'user3' getting access to the table created by 'user1' through the view. I remember a discussion on the list to raise an error when an attempt is execute a GRANT on the view, until WITH GRANT option is implemented. Here is the repro: java -cp derby.jar;.\derbytools.jar -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij select_table_no_privilege.sql ij version 10.2 ij -- --create db as user1 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1(id int); 0 rows inserted/updated/deleted ij insert into t1 values(100); 1 row inserted/updated/deleted ij insert into t1 values(200); 1 row inserted/updated/deleted ij -- --Grant select to user2 -- grant select on t1 to user2; 0 rows inserted/updated/deleted ij -- --Connect as user2 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user2'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existingdatabase instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION1) select * from user1.t1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Create view -- create view v1 as select * from user1.t1; 0 rows inserted/updated/deleted ij(CONNECTION1) select * from v1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Grant select on view to user3. With the WITH GRANT option this should have failed -- grant select on v1 to user3; 0 rows inserted/updated/deleted ij(CONNECTION1) -- --Connect as user3 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user3'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION2) -- --No select privilege on base table user1.t1, hence will FAIL -- select * from user1.t1; ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(Unknown Source) at org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.fillResultSet(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at
[jira] Updated: (DERBY-1686) Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail
[ http://issues.apache.org/jira/browse/DERBY-1686?page=all ] Yip Ng updated DERBY-1686: -- Attachment: derby1686-trunk-stat03.txt derby1686-trunk-diff03.txt Attaching derby1686-trunk-diff03.txt. This patch removes the dba check at bind time and will collect the providers of a view regardless who the object owner is. The runtime will check the authorization. Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail --- Key: DERBY-1686 URL: http://issues.apache.org/jira/browse/DERBY-1686 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Any Reporter: Rajesh Kartha Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1686-trunk-diff01.txt, derby1686-trunk-diff02.txt, derby1686-trunk-diff03.txt, derby1686-trunk-stat01.txt, derby1686-trunk-stat02.txt, derby1686-trunk-stat03.txt, select_table_no_privilege.sql With authentication on, attempting to execute a GRANT privilege to 'user3' on a VIEW created by the 'user2' - who has only SELECT privilege on the base table created by 'user1' does not fail. This results in 'user3' getting access to the table created by 'user1' through the view. I remember a discussion on the list to raise an error when an attempt is execute a GRANT on the view, until WITH GRANT option is implemented. Here is the repro: java -cp derby.jar;.\derbytools.jar -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij select_table_no_privilege.sql ij version 10.2 ij -- --create db as user1 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1(id int); 0 rows inserted/updated/deleted ij insert into t1 values(100); 1 row inserted/updated/deleted ij insert into t1 values(200); 1 row inserted/updated/deleted ij -- --Grant select to user2 -- grant select on t1 to user2; 0 rows inserted/updated/deleted ij -- --Connect as user2 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user2'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existingdatabase instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION1) select * from user1.t1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Create view -- create view v1 as select * from user1.t1; 0 rows inserted/updated/deleted ij(CONNECTION1) select * from v1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Grant select on view to user3. With the WITH GRANT option this should have failed -- grant select on v1 to user3; 0 rows inserted/updated/deleted ij(CONNECTION1) -- --Connect as user3 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user3'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION2) -- --No select privilege on base table user1.t1, hence will FAIL -- select * from user1.t1; ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(Unknown Source) at org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.fillResultSet(Unknown Source) at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax0011df100.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at
[jira] Assigned: (DERBY-1702) lang/outparams.java and jdbcapi/parameterMapping.java fail on J9 ibm 131 jvm .
[ http://issues.apache.org/jira/browse/DERBY-1702?page=all ] Myrna van Lunteren reassigned DERBY-1702: - Assignee: Myrna van Lunteren lang/outparams.java and jdbcapi/parameterMapping.java fail on J9 ibm 131 jvm . --- Key: DERBY-1702 URL: http://issues.apache.org/jira/browse/DERBY-1702 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.3.0.0, 10.2.2.0 Environment: ava user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\cloudtst\jartest\JarResults.2006-08-11\wsdd5.6_derbyall java.specification.name: Java Platform API Specification java.specification.version: 1.3 Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Fix For: 10.3.0.0, 10.2.2.0 Attachments: outparams.diff, outparams.out, parameterMapping.diff diffs : Exception SQL Exception: No input parameters. 27a27 Exception java.sql.SQLException: No input parameters. 29 del Exception SQL Exception: No input parameters. 29a29 most probaly a master update issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Question on the lib 10.2.1.1beta layout
I downloaded db-derby-10.2.1.1-lib.zip from http://people.apache.org/~rhillegas/10.2.1.1-beta/ The layout wasn't what I was expecting, the top level had two folders: db-derby-10.2.1.1-bin db-derby-10.2.1.1-lib The bin folder had the test folder and the bin had the lib folder. Is this intentional, to have two top-level folders, I guess I was expecting a single folder with test and lib underneath it? Dan.
[jira] Updated: (DERBY-1566) Document SQLStates in 10.2
[ http://issues.apache.org/jira/browse/DERBY-1566?page=all ] Jean T. Anderson updated DERBY-1566: Attachment: ErrorMessageGenerator.java rrefexcept71493.html ErrorMessageGenerator.java is a copy of DERBY-296's app modified as follows: 1) Replaced the -//IBM//DTD DITA Reference//EN with -//OASIS//DTD DITA Reference//EN 2) Some tags needed a space . For example, the 'xml' in this tag: reference id=rrefexcept13113xml:lang=en-us needed a space before the 'xml' so xml parsing would succeed: reference id=rrefexcept13113 xml:lang=en-us 3) Needed some close tags for DITA processing to succeed. Running it outputs two errors: $ java ErrorMessageGenerator Unable to determine code for SQL State 0A000 Unable to determine code for SQL State 39004 The DITA source that it generates needs one manual change. The message for 42Y04 has '' and '' in the message. Change this: full java path.method name To this: lt;full java pathgt;.lt;method namegt; rrefexcept71493.html shows sample output. Document SQLStates in 10.2 -- Key: DERBY-1566 URL: http://issues.apache.org/jira/browse/DERBY-1566 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.2.1.0 Reporter: Rick Hillegas Assigned To: David Van Couvering Fix For: 10.2.1.0 Attachments: ErrorMessageGenerator.java, rrefexcept71493.html We need to update the Reference Guide to document the current list of SQLStates. This list goes into Reference Guide Derby exception messages and SQL states SQLState and error message reference The tool mentioned in DERBY-296 may be useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1702) lang/outparams.java and jdbcapi/parameterMapping.java fail on J9 ibm 131 jvm .
[ http://issues.apache.org/jira/browse/DERBY-1702?page=all ] Myrna van Lunteren updated DERBY-1702: -- Attachment: DERBY-1702-main_20060828.diff DERBY-1702_102_20060828.diff 2 patches - 1 for the trunk 1 for 10.2 - with relevant master updates. lang/outparams.java and jdbcapi/parameterMapping.java fail on J9 ibm 131 jvm . --- Key: DERBY-1702 URL: http://issues.apache.org/jira/browse/DERBY-1702 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.3.0.0, 10.2.2.0 Environment: ava user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\cloudtst\jartest\JarResults.2006-08-11\wsdd5.6_derbyall java.specification.name: Java Platform API Specification java.specification.version: 1.3 Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Fix For: 10.3.0.0, 10.2.2.0 Attachments: DERBY-1702-main_20060828.diff, DERBY-1702_102_20060828.diff, outparams.diff, outparams.out, parameterMapping.diff diffs : Exception SQL Exception: No input parameters. 27a27 Exception java.sql.SQLException: No input parameters. 29 del Exception SQL Exception: No input parameters. 29a29 most probaly a master update issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1771) Doc title in browser for html pages is Web sample
Doc title in browser for html pages is Web sample -- Key: DERBY-1771 URL: http://issues.apache.org/jira/browse/DERBY-1771 Project: Derby Issue Type: Bug Reporter: Daniel John Debrunner docs/html/ref/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1702) lang/outparams.java and jdbcapi/parameterMapping.java fail on J9 ibm 131 jvm .
[ http://issues.apache.org/jira/browse/DERBY-1702?page=all ] Myrna van Lunteren updated DERBY-1702: -- Derby Info: [Patch Available, Regression] (was: [Regression]) lang/outparams.java and jdbcapi/parameterMapping.java fail on J9 ibm 131 jvm . --- Key: DERBY-1702 URL: http://issues.apache.org/jira/browse/DERBY-1702 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.3.0.0, 10.2.2.0 Environment: ava user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\cloudtst\jartest\JarResults.2006-08-11\wsdd5.6_derbyall java.specification.name: Java Platform API Specification java.specification.version: 1.3 Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Fix For: 10.3.0.0, 10.2.2.0 Attachments: DERBY-1702-main_20060828.diff, DERBY-1702_102_20060828.diff, outparams.diff, outparams.out, parameterMapping.diff diffs : Exception SQL Exception: No input parameters. 27a27 Exception java.sql.SQLException: No input parameters. 29 del Exception SQL Exception: No input parameters. 29a29 most probaly a master update issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1771) Doc title in browser for html pages is Web sample
[ http://issues.apache.org/jira/browse/DERBY-1771?page=all ] Daniel John Debrunner updated DERBY-1771: - Description: Loadin this page in the broswer shows the title: docs/html/ref/index.html Also seen on the docs on the web-site. http://db.apache.org/derby/docs/dev/ref/ Be good if the page tltle was related to its contents, e.g. Derby Reference Manual was: docs/html/ref/index.html Doc title in browser for html pages is Web sample -- Key: DERBY-1771 URL: http://issues.apache.org/jira/browse/DERBY-1771 Project: Derby Issue Type: Bug Reporter: Daniel John Debrunner Loadin this page in the broswer shows the title: docs/html/ref/index.html Also seen on the docs on the web-site. http://db.apache.org/derby/docs/dev/ref/ Be good if the page tltle was related to its contents, e.g. Derby Reference Manual -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4
[ http://issues.apache.org/jira/browse/DERBY-1633?page=comments#action_12431123 ] Prasenjit Sarkar commented on DERBY-1633: - Our application is too network-server centric to run in embedded mode. I would like to help you in any other way, but retrofitting our application is not feasible at this point. On the whole, it looks like a new issue. Regression: The fields of views are not being calculated properly since 10.1.2.4 Key: DERBY-1633 URL: http://issues.apache.org/jira/browse/DERBY-1633 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.0, 10.1.3.1 Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory Reporter: Prasenjit Sarkar Assigned To: A B Fix For: 10.2.1.0, 10.3.0.0, 10.1.3.2 Attachments: d1633_10_1_merge.patch, d1633_repro.sql, d1633_v1_reviewOnly.patch, d1633_v2.patch, d1633_v3_code.patch, d1633_v3_tests.patch, DERBY-1633_v1.html, DERBY-1633_v2.html, DERBY-1633_v3.html Database can be assumed to be same as in Derby - 1205 Jira issue SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID This works fine in 10.1.2.1 but fails thereafter complaining that Comparison between INTEGER and CHAR is not supported for some reason, it thinks one of the PORT_ID columns is a character, when in reality both are integers. SELECT DISTINCT ZONE.ZONE_ID ZONE_ID, PORT2ZONE.ZONE_MEMBER_ID FROM T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE PORT2ZONE on ZONE.ZONE_ID = PORT2ZONE.ZONE_ID , T_RES_FABRIC FABRIC In this query, it is complaining that one of the columns is a VARCHAR and cannot be compared to INTEGER, when clearly this is not the case... Same issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
XML type description - possible changes?
The XML type has this description in the reference manual: http://db.apache.org/derby/docs/dev/ref/rrefsqljtypexml.html An XML column is used to store Unicode character-based data, such as large documents in any character set, that conform to the SQL/XML definition of a well-formed XML(DOCUMENT(ANY)) value. An XML value can be up to 2,147,483,647 characters long That seems wrong to me, the use of store Unicode character-based, any implementation details are not important here. Also the use of large is not relevant, what about small XML documents? Looking at the other type definitions it seems something like this would match, though it seems unwieldy. XML provides for storage of Extensible Markup Language (XML) documents, that conform to the SQL/XML definition of a well-formed XML(DOCUMENT(ANY)) value. Also I'm not sure about the character limitation on the XML value, is that the limit on the input string to the document, or its final storage? Not sure describing the final stored limit in terms of characters makes sense here. Dan.
[jira] Commented: (DERBY-1566) Document SQLStates in 10.2
[
http://issues.apache.org/jira/browse/DERBY-1566?page=comments#action_12431128 ]
Jean T. Anderson commented on DERBY-1566:
-
Compare rrefexcept71493.html uploaded to this issue to
http://db.apache.org/derby/docs/10.1/ref/rrefexcept71493.html. Readily visible
differences include:
1) The old output has human-readable tags such as tableName and valueName
and the new generated output has {0}, {1}, etc. variable markers. I think the
human-readable tags would be very labor-intensive to maintain.
2) The new output includes a severity column
Lots of sqlstates drop out in 10.2 and others get added. I'll try to summarize
a list and post it tomorrow.
Document SQLStates in 10.2
--
Key: DERBY-1566
URL: http://issues.apache.org/jira/browse/DERBY-1566
Project: Derby
Issue Type: Improvement
Components: Documentation
Affects Versions: 10.2.1.0
Reporter: Rick Hillegas
Assigned To: David Van Couvering
Fix For: 10.2.1.0
Attachments: ErrorMessageGenerator.java, rrefexcept71493.html
We need to update the Reference Guide to document the current list of
SQLStates. This list goes into
Reference Guide
Derby exception messages and SQL states
SQLState and error message reference
The tool mentioned in DERBY-296 may be useful.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1772) Error 42Z78 Failed to locate 'Xalan' API classes should not have sqlstate class '42'
Error 42Z78 Failed to locate 'Xalan' API classes should not have sqlstate class '42' --- Key: DERBY-1772 URL: http://issues.apache.org/jira/browse/DERBY-1772 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Reporter: Daniel John Debrunner Priority: Minor This is a run-time error but it has the SQL state '42' for compile error, and thus in Java SE 6 will have a SQLException of type SQLSyntaxErrorException. ERROR 38000: The exception 'java.sql.SQLSyntaxErrorException: Failed to locate ' Xalan' API or implementation classes. XML operations are not permitted unless t hese classes are in your classpath.' was thrown while evaluating an expression. ERROR 42Z78: Failed to locate 'Xalan' API or implementation classes. XML operat ions are not permitted unless these classes are in your classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1583) With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE
[ http://issues.apache.org/jira/browse/DERBY-1583?page=all ] Bryan Pendleton updated DERBY-1583: --- Attachment: skipAddPriv.diff Attached is an alternate proposal for a patch to this issue. skipAddPriv.diff is based on the idea that if a particular ColumnDescriptor has no associated TableDescriptor at the time that CompilerContextImpl.addRequiredColumnPriv is called, then there is no column privilege that needs to be added. This patch passes derbyall, and in particular the update.sql test which failed with the previous patch proposal does not fail with this patch proposal. Moreover, I successfully tested the DERBY-1754 test case as well as the test case for this bug (the test case for this bug is included in the diff as a new regression test). Please have a look at this patch proposal and let me know what you think. With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE -- Key: DERBY-1583 URL: http://issues.apache.org/jira/browse/DERBY-1583 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Reporter: Mamta A. Satoor Assigned To: Bryan Pendleton Fix For: 10.2.1.0 Attachments: setTableDescriptor.diff, setTableDescriptor.diff, skipAddPriv.diff While working on SQL authorization work, I ran across a test case where Derby will throw a NPE when a trigger is defined with it's action as update a table from another schema. I don't have much details on why but following is the test case. Derby is trying to put privilege requirement for a column into privilege requirements list and it expects the column's tableUUID to be not null but in this particular case, it is null. connect 'jdbc:derby:c:/dellater/dbmain;create=true' user 'mamta1' as mamta1; create table t11TriggerRevokeTest (c111 int not null primary key, c12 int); grant TRIGGER on t11TriggerRevokeTest to mamta2; create table t12TriggerRevokeTest (c121 int, c122 int, c123 int); grant UPDATE(c122, c121) on t12TriggerRevokeTest to mamta2; connect 'jdbc:derby:c:/dellater/dbmain;create=true' user 'mamta2' as mamta2; create trigger tr11t11 after insert on mamta1.t11TriggerRevokeTest for each statement mode db2sql update mamta1.t12TriggerRevokeTest set c122 = 99; The stack trace looks as follows ij(MAMTA2) ERROR XJ001: Java exception: ': java.lang.NullPointerException'.java.lang.NullPointerException at org.apache.derby.impl.sql.compile.CompilerContextImpl.addRequiredColumnPriv(CompilerContextImpl.java:741) at org.apache.derby.impl.sql.compile.ResultColumn.bindResultColumnByName(ResultColumn.java:682) at org.apache.derby.impl.sql.compile.ResultColumnList.bindResultColumnsByName(ResultColumnList.java:635) at org.apache.derby.impl.sql.compile.ResultSetNode.bindResultColumns(ResultSetNode.java:682) at org.apache.derby.impl.sql.compile.SelectNode.bindResultColumns(SelectNode.java:751) at org.apache.derby.impl.sql.compile.UpdateNode.bind(UpdateNode.java:348) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:344) at org.apache.derby.impl.sql.GenericStatement.prepareStorable(GenericStatement.java:591) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(SPSDescriptor.java:353) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:283) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(CreateTriggerConstantAction.java:367) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(CreateTriggerConstantAction.java:272) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:357) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:207) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:173) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) -- This message is automatically generated by
[jira] Commented: (DERBY-1686) Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail
[ http://issues.apache.org/jira/browse/DERBY-1686?page=comments#action_12431141 ] Mamta A. Satoor commented on DERBY-1686: Yip, I thought more about this issue and I think we might be able to get away with an easier solution. With SQL authorization mode, for a view, in sys.sysdepends table, there will be zero/more rows for privilege dependencies. If the database owner is the owner of the view, then there will be no privilege dependencies rows in sys.sysdepends table. For a view whose owner is not the database owner, there will be no privilege dependencies rows in sys.sysdepends table if the view is not accessing any objects outside of the schema owned by the view owner. So, no privilege dependencies rows in sys.sysdepends table for a view would mean that the view owner can grant access to the view to other users. If there are privilege dependencies rows in sys.sysdepends table for a view, then that would mean that the view is relying on privileges on external objects and hence, the view owner will not be able to grant access to the view to other users (the exception to this rule would be if the database owner is trying to grant access to any view to any user. That should work no matter if there are zero or more privilege dependencies rows in sys.sysdepends table for the view). So, rather than building a list of providers for a view, we can simply have a flag which will be set to true at compile time if there are privilege dependencies rows in sys.sysdepends table for the given view. At execute time, if the grantor is the database owner, then we wil not worry about the flag and will succesfully grant the view access to the grantee. But if the grantor is the view owner and the flag is set to true, then we should throw an exception because the view owner does not own all the objects accessed by the view. I might not have thought over everything, so do let me know, if you find something in my proposed logic that might not work. Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail --- Key: DERBY-1686 URL: http://issues.apache.org/jira/browse/DERBY-1686 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Any Reporter: Rajesh Kartha Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1686-trunk-diff01.txt, derby1686-trunk-diff02.txt, derby1686-trunk-diff03.txt, derby1686-trunk-stat01.txt, derby1686-trunk-stat02.txt, derby1686-trunk-stat03.txt, select_table_no_privilege.sql With authentication on, attempting to execute a GRANT privilege to 'user3' on a VIEW created by the 'user2' - who has only SELECT privilege on the base table created by 'user1' does not fail. This results in 'user3' getting access to the table created by 'user1' through the view. I remember a discussion on the list to raise an error when an attempt is execute a GRANT on the view, until WITH GRANT option is implemented. Here is the repro: java -cp derby.jar;.\derbytools.jar -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij select_table_no_privilege.sql ij version 10.2 ij -- --create db as user1 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1(id int); 0 rows inserted/updated/deleted ij insert into t1 values(100); 1 row inserted/updated/deleted ij insert into t1 values(200); 1 row inserted/updated/deleted ij -- --Grant select to user2 -- grant select on t1 to user2; 0 rows inserted/updated/deleted ij -- --Connect as user2 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user2'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existingdatabase instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION1) select * from user1.t1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Create view -- create view v1 as select * from user1.t1; 0 rows inserted/updated/deleted ij(CONNECTION1) select * from v1; ID --- 100 200 2 rows selected ij(CONNECTION1) -- --Grant select on view to user3. With the WITH GRANT option this should have failed -- grant select on v1 to user3; 0 rows inserted/updated/deleted ij(CONNECTION1) -- --Connect as user3 -- connect 'jdbc:derby:grntrevokedb;create=true' user 'user3'; WARNING 01J01: Database 'grntrevokedb' not created, connection made to existing database instead. WARNING 01J14: SQL
[jira] Commented: (DERBY-1583) With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE
[ http://issues.apache.org/jira/browse/DERBY-1583?page=comments#action_12431143 ] Mamta A. Satoor commented on DERBY-1583: Bryan, the patch looks good to me. Just couple minor comments 1)Can you please put a comment for if (td == nulll) check in CompilerContextImpl.addRequiredColumnPriv which says when this if condition will be true and may be reference to this jira entry in that comment? 2)Also, in the new test case for create trigger with update as trigger action, can you add couple dmls which demonstrates that the trigger gets fired and does what it is expected to do? Then revoke one of the required privileges to show that trigger gets dropped and some dmls after that which will show that the trigger doesn't fire anymore. Thanks for working on this issue With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE -- Key: DERBY-1583 URL: http://issues.apache.org/jira/browse/DERBY-1583 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Reporter: Mamta A. Satoor Assigned To: Bryan Pendleton Fix For: 10.2.1.0 Attachments: setTableDescriptor.diff, setTableDescriptor.diff, skipAddPriv.diff While working on SQL authorization work, I ran across a test case where Derby will throw a NPE when a trigger is defined with it's action as update a table from another schema. I don't have much details on why but following is the test case. Derby is trying to put privilege requirement for a column into privilege requirements list and it expects the column's tableUUID to be not null but in this particular case, it is null. connect 'jdbc:derby:c:/dellater/dbmain;create=true' user 'mamta1' as mamta1; create table t11TriggerRevokeTest (c111 int not null primary key, c12 int); grant TRIGGER on t11TriggerRevokeTest to mamta2; create table t12TriggerRevokeTest (c121 int, c122 int, c123 int); grant UPDATE(c122, c121) on t12TriggerRevokeTest to mamta2; connect 'jdbc:derby:c:/dellater/dbmain;create=true' user 'mamta2' as mamta2; create trigger tr11t11 after insert on mamta1.t11TriggerRevokeTest for each statement mode db2sql update mamta1.t12TriggerRevokeTest set c122 = 99; The stack trace looks as follows ij(MAMTA2) ERROR XJ001: Java exception: ': java.lang.NullPointerException'.java.lang.NullPointerException at org.apache.derby.impl.sql.compile.CompilerContextImpl.addRequiredColumnPriv(CompilerContextImpl.java:741) at org.apache.derby.impl.sql.compile.ResultColumn.bindResultColumnByName(ResultColumn.java:682) at org.apache.derby.impl.sql.compile.ResultColumnList.bindResultColumnsByName(ResultColumnList.java:635) at org.apache.derby.impl.sql.compile.ResultSetNode.bindResultColumns(ResultSetNode.java:682) at org.apache.derby.impl.sql.compile.SelectNode.bindResultColumns(SelectNode.java:751) at org.apache.derby.impl.sql.compile.UpdateNode.bind(UpdateNode.java:348) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:344) at org.apache.derby.impl.sql.GenericStatement.prepareStorable(GenericStatement.java:591) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(SPSDescriptor.java:353) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:283) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(CreateTriggerConstantAction.java:367) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(CreateTriggerConstantAction.java:272) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:357) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:207) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:173) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly
