[jira] Resolved: (DERBY-1608) Execution of builtin functions by a user who is not the owner of system schemas gives NPE when authentication and SQL authorization are on.
[ http://issues.apache.org/jira/browse/DERBY-1608?page=all ]
Satheesh Bandaram resolved DERBY-1608.
--
Resolution: Fixed
Submitted a fix to trunk and also added test cases.
Execution of builtin functions by a user who is not the owner of system
schemas gives NPE when authentication and SQL authorization are on.
---
Key: DERBY-1608
URL: http://issues.apache.org/jira/browse/DERBY-1608
Project: Derby
Issue Type: Bug
Components: SQL
Reporter: Deepa Remesh
Assigned To: Satheesh Bandaram
Fix For: 10.2.0.0
1. Create a database in 10.1
2. Full upgrade to 10.2 - Booting using 10.2 jars by specifying
upgrade=true in the connection URL.
3. Execute a function e.g: VALUES { fn ACOS(0.0707) }. This passes as
expected.
4. Set database property derby.database.sqlAuthorization=true.
5. Shutdown and reconnect to database for the property to take effect.
6. Re-execute the function. This gives NPE.
Repro using ij:
Steps using 10.1 jar:
ij version 10.1
ij connect 'jdbc:derby:old_db;create=true';
ij exit;
Steps using 10.2 jar:
ij version 10.2
ij connect 'jdbc:derby:old_db;upgrade=true';
ij VALUES { fn ACOS(0.0707) };
1
--
1.5000372950430991
1 row selected
ij call
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.sqlAuthorization',
'true');
0 rows inserted/updated/deleted
ij connect 'jdbc:derby:old_db;shutdown=true';
ERROR 08006: Database 'old_db' shutdown.
ij connect 'jdbc:derby:old_db';
ij(CONNECTION1) VALUES { fn ACOS(0.0707) };
ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
ij(CONNECTION1)
Stack trace of failure:
ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
java.lang.NullPointerException
at
org.apache.derby.iapi.sql.dictionary.RoutinePermsDescriptor.init(RoutinePermsDescriptor
.java:54)
at
org.apache.derby.iapi.sql.dictionary.RoutinePermsDescriptor.init(RoutinePermsDescriptor
.java:62)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getRoutinePermissions(DataDictionary
Impl.java:9902)
at
org.apache.derby.iapi.sql.dictionary.StatementRoutinePermission.check(StatementRoutinePer
mission.java:55)
at
org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(GenericAuthorizer.java:157)
at
org.apache.derby.exe.ac6b91c056x010cxb687x3eb7x0012d1c00.fillResultSet(Unknown
Source
)
at
org.apache.derby.exe.ac6b91c056x010cxb687x3eb7x0012d1c00.execute(Unknown
Source)
at
org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:32
6)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:
355)
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:312)
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] Updated: (DERBY-1619) Sysinfo in 10.2 shows multiple entries if the derby jars reside in a directory with spaces in its name
[ http://issues.apache.org/jira/browse/DERBY-1619?page=all ]
Andrew McIntyre updated DERBY-1619:
---
Attachment: derby-1619-v1.diff
Attached is a simple patch to convert URL spaces ('%20') to real spaces when
comparing filenames in sysinfo. This should prevent duplicate entries in the
sysinfo output when there are spaces in the full path as discovered by
getResource vs. as discovered via the classpath.
I would appreciate it if the reporter of this issue could try out this patch
and let me know if this resolves the issue.
Sysinfo in 10.2 shows multiple entries if the derby jars reside in a
directory with spaces in its name
---
Key: DERBY-1619
URL: http://issues.apache.org/jira/browse/DERBY-1619
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.0.0
Environment: Windows XP, jdk 1.5
Reporter: Rajesh Kartha
Assigned To: Andrew McIntyre
Fix For: 10.2.0.0
Attachments: derby-1619-v1.diff
For the Derby jars residing in C:\Documents and Settings\Administrator\TEMP
DIR\lib, the sysinfo shows:
- Derby Information
JRE - JDBC: J2SE 5.0 - JDBC 3.0
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derby.jar]
10.2.0.5 alpha - (426734)
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbytools.jar]
10.2.0.5 alpha - (426734)
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbynet.jar]
10.2.0.5 alpha - (426734)
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbyclient.jar]
10.2.0.5 alpha - (426734)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.2.0.5
alpha - (426734)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.2.0.5
alpha - (426734)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar]
10.2.0.5 alpha - (426734)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar]
10.2.0.5 alpha - (426734)
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\db2jcc.jar] 2.6 -
(90)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar]
2.6 - (90)
--
This is a regression from 10.1 where the same sysinfo shows:
- Derby Information
JRE - JDBC: J2SE 5.0 - JDBC 3.0
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.1.3.2 -
(426741)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.1.3.2
- (426741)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar]
10.1.3.2 - (426741)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar]
10.1.3.2 - (426741)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc.jar] 2.6 - (90)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar]
2.6 - (90)
--
--
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
Regression Test Failure! - Derby 427184 - Sun DBTG
[Auto-generated mail] *Derby* 427184/2006-07-31 19:46:09 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 16729713 0 107.21% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-427184.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/427184.html *Jvm: 1.5* 2685683 2 103.88% CYGWIN_NT-5.1_i686-unknown 4685681 2 118.10% CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 NA NA NANA Linux-2.6.9-34.ELsmp_x86_64-x86_64 1685684 2 180.51% SunOS-5.10_i86pc-i386 1685684 2 138.37% SunOS-5.10_sun4u-sparc 2685683 2 110.07% SunOS-5.11_i86pc-i386 3685682 2 136.54% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-427184.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/427184.html *Jvm: 1.4* 2679677 4 101.63% CYGWIN_NT-5.1_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 NA NA NANA Linux-2.6.9-34.ELsmp_x86_64-x86_64 1679678 4 217.48% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-427184.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/427184.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/427184.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Patches for DERBY-1609 (was: Re: svn commit: r427293 - in /db/derby/code/trunk/java/tools/org/apache/derby/impl/tools/ij: Main.java mtTestCase.java utilMain.java utilMain14.java)
Daniel John Debrunner wrote: I think I fixed them, just checking in another codeline. I'malso changing wisconsin.java to use the new ij.runScript method so I didn't see that compile error. The change to use runScript isn't ready yet, some diffs exist ddue to a cursor name. Dan, Speaking of the new ij.runScript method, is there any chance you will upload any patches to DERBY-1609 (Jira) in the future? I'm not a big fan of the commit-then-review-by-inspecting-svn-history process when it comes to new features like this. With patches attached to Jira it is easier for members of the community to learn from the code and/or spot mistakes, without having to subscribe to the derby-commits list. -- John
[jira] Commented: (DERBY-1616) Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException
[ http://issues.apache.org/jira/browse/DERBY-1616?page=comments#action_12424804 ] Kristian Waagan commented on DERBY-1616: Just want to inform that the jdbc40 suite now runs without failures (with JDK1.6). All planned interface changes have been made, and if the tests fail again, that means a new issue requiring attention has popped up. If you are running with Mustang, please use a recent build. Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException - Key: DERBY-1616 URL: http://issues.apache.org/jira/browse/DERBY-1616 Project: Derby Issue Type: Bug Affects Versions: 10.2.0.0 Environment: jdk16 /windows. Reporter: Sunitha Kambhampati Fix For: 10.2.0.0 Attachments: derbyall_report.txt jdk16 derbyall derbyall: 19 failures derbyall/derbyall.fail:lang/compressTable.sql derbyall/derbyall.fail:lang/nestedCommit.sql derbyall/derbyall.fail:lang/outparams.java derbyall/derbyall.fail:lang/procedure.java derbyall/derbyall.fail:lang/procedureInTrigger.sql derbyall/derbyall.fail:tools/importExportThruIJ.sql derbyall/derbyall.fail:tools/ieptests.sql derbyall/derbyall.fail:tools/iepnegativetests.sql derbyall/derbyall.fail:jdbcapi/statementJdbc20.java derbyall/derbyall.fail:jdbcapi/statementJdbc30.java derbyall/derbyall.fail:jdbcapi/parameterMapping.java derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/ClosedObjectTest.junit derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/UnsupportedVetter.junit derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/VerifySignatures.junit derbyall/encryptionAll/encryption.fail:stress/stress.multi derbyall/encryptionAll/storemats.fail:store/streamingColumn.java derbyall/storeall/storeall.fail:store/TransactionTable.sql derbyall/storeall/storemats.fail:store/streamingColumn.java -- 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
Building 10.2
Greetings all, Just a Heads up, If you DON'T FOLLOW THE BUILDING.txt and install jdbc2_0-stdext.jar You get the following error. Oh and this has nothing to do with JSR169, the compile_jsr169: can be miss leading compile_jsr169: [javac] Compiling 1 source file to C:\Derby\10.2\classes [javac] [parsing started C:\Derby\10.2\java\engine\org\apache\derby\jdbc\EmbeddedSimpleDataSource.java] [javac] [parsing completed 157ms] [javac] [search path for source files: [C:\Derby\10.2\java\engine]] [javac] [search path for class files: [C:\Program Files\Java\jdk1.5.0_07\jre\lib\ext\dnsns.jar, C:\Program Files\Java\jdk1.5.0_07\jre\lib\ext\localedata.jar, C:\Program Files\Java\jdk1.5.0_07\jre\lib\ext\sunjce_provider.jar, C:\Program Files\Java\jdk1.5.0_07\jre\lib\ext\sunpkcs11.jar, C:\Derby\10.2\classes, C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar]] [javac] [loading C:\Derby\10.2\classes\org\apache\derby\iapi\jdbc\JDBCBoot.class] [javac] [loading C:\Derby\10.2\classes\org\apache\derby\iapi\reference\Attribute.class] [javac] [loading C:\Derby\10.2\classes\org\apache\derby\iapi\reference\MessageId.class] [javac] [loading C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar(java/sql/Connection.class)] [javac] [loading C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar(java/sql/SQLException.class)] [javac] [loading C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar(java/io/PrintWriter.class)] [javac] [loading C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar(java/util/Properties.class)] [javac] C:\Derby\10.2\java\engine\org\apache\derby\jdbc\EmbeddedSimpleDataSource.java:34: package javax.sql does not exist [javac] import javax.sql.DataSource; [javac] ^ [javac] [loading C:\Derby\10.2\classes\org\apache\derby\iapi\reference\SQLState.class] Regards X
Regression Test Failure! - TinderBox_Derby 427354 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 427354/2006-08-01 01:12:25 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 3682679 2 541.99% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-427354.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/427354.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/427354.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Building 10.2 Errors
Greetings all, Just a Heads up, If you DON'T FOLLOW THE BUILDING.txt and install jdbc2_0-stdext.jar You get the following error. Oh and this has nothing to do with JSR169, the compile_jsr169: can be miss leading compile_jsr169: [javac] Compiling 1 source file to C:\Derby\10.2\classes [javac] [parsing started C:\Derby\10.2\java\engine\org\apache\derby\jdbc\EmbeddedSimpleDataSource.java] [javac] [parsing completed 157ms] [javac] [search path for source files: [C:\Derby\10.2\java\engine]] [javac] [search path for class files: [C:\Program Files\Java\jdk1.5.0_07\jre\lib\ext\dnsns.jar, C:\Program Files\Java\jdk1.5.0_07\jre\lib\ext\localedata.jar, C:\Program Files\Java\jdk1.5.0_07\jre\lib\ext\sunjce_provider.jar, C:\Program Files\Java\jdk1.5.0_07\jre\lib\ext\sunpkcs11.jar, C:\Derby\10.2\classes, C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar]] [javac] [loading C:\Derby\10.2\classes\org\apache\derby\iapi\jdbc\JDBCBoot.class] [javac] [loading C:\Derby\10.2\classes\org\apache\derby\iapi\reference\Attribute.class] [javac] [loading C:\Derby\10.2\classes\org\apache\derby\iapi\reference\MessageId.class] [javac] [loading C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar(java/sql/Connection.class)] [javac] [loading C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar(java/sql/SQLException.class)] [javac] [loading C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar(java/io/PrintWriter.class)] [javac] [loading C:\Progra~1\Java\jre1.3.1_04\lib\rt.jar(java/util/Properties.class)] [javac] C:\Derby\10.2\java\engine\org\apache\derby\jdbc\EmbeddedSimpleDataSource.java:34: package javax.sql does not exist [javac] import javax.sql.DataSource; [javac] ^ [javac] [loading C:\Derby\10.2\classes\org\apache\derby\iapi\reference\SQLState.class] Regards X
[jira] Commented: (DERBY-1619) Sysinfo in 10.2 shows multiple entries if the derby jars reside in a directory with spaces in its name
[
http://issues.apache.org/jira/browse/DERBY-1619?page=comments#action_12424832 ]
John H. Embretsen commented on DERBY-1619:
--
I tried derby-1619-v1.diff, and it works as a remedy against the spaces in
path issue. However:
The same thing happens if other special characters that are escaped in an URL
are used in the jar path. For example, with the path
/export/home/tmp/Derby/jar-path-with%percentage-sign
on a Solaris machine, sysinfo ('java org.apache.derby.tools.sysinfo') reports
- Derby Information
JRE - JDBC: J2SE 5.0 - JDBC 3.0
[/export/home/tmp/Derby/jar-path-with%25percentage-sign/derby.jar] 10.2.0.5
alpha - (427500)
[/export/home/tmp/Derby/jar-path-with%25percentage-sign/derbytools.jar]
10.2.0.5 alpha - (427500)
[/export/home/tmp/Derby/jar-path-with%25percentage-sign/derbynet.jar] 10.2.0.5
alpha - (427500)
[/export/home/tmp/Derby/jar-path-with%25percentage-sign/derbyclient.jar]
10.2.0.5 alpha - (427500)
[/export/home/tmp/Derby/jar-path-with%percentage-sign/derby.jar] 10.2.0.5 alpha
- (427500)
[/export/home/tmp/Derby/jar-path-with%percentage-sign/derbynet.jar] 10.2.0.5
alpha - (427500)
[/export/home/tmp/Derby/jar-path-with%percentage-sign/derbytools.jar] 10.2.0.5
alpha - (427500)
[/export/home/tmp/Derby/jar-path-with%percentage-sign/derbyclient.jar] 10.2.0.5
alpha - (427500)
This is not an issue when running sysinfo by doing 'java -jar derbyrun.jar
sysinfo'.
Quoting from http://www.ietf.org/rfc/rfc2396.txt (section 2.4.2):
Because the percent % character always has the reserved purpose of
being the escape indicator, it must be escaped as %25 in order to
be used as data within a URI. Implementers should be careful not to
escape or unescape the same string more than once, since unescaping
an already unescaped string might lead to misinterpreting a percent
data character as another escaped character, or vice versa in the
case of escaping an already escaped string.
(end quote)
I'm not sure how this is normally handled in the java world.
We could try to fix this, or document it as normal sysinfo behavior (if not
run via 'java -jar') when using special characters in the code/jar path.
I don't know which characters Java usually escapes in URLs, but the most
important ones are listed in RFC-2396. Other posibilities are listed here:
http://www.degraeve.com/reference/urlencoding.php
Sysinfo in 10.2 shows multiple entries if the derby jars reside in a
directory with spaces in its name
---
Key: DERBY-1619
URL: http://issues.apache.org/jira/browse/DERBY-1619
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.0.0
Environment: Windows XP, jdk 1.5
Reporter: Rajesh Kartha
Assigned To: Andrew McIntyre
Fix For: 10.2.0.0
Attachments: derby-1619-v1.diff
For the Derby jars residing in C:\Documents and Settings\Administrator\TEMP
DIR\lib, the sysinfo shows:
- Derby Information
JRE - JDBC: J2SE 5.0 - JDBC 3.0
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derby.jar]
10.2.0.5 alpha - (426734)
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbytools.jar]
10.2.0.5 alpha - (426734)
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbynet.jar]
10.2.0.5 alpha - (426734)
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbyclient.jar]
10.2.0.5 alpha - (426734)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.2.0.5
alpha - (426734)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.2.0.5
alpha - (426734)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar]
10.2.0.5 alpha - (426734)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar]
10.2.0.5 alpha - (426734)
[C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\db2jcc.jar] 2.6 -
(90)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar]
2.6 - (90)
--
This is a regression from 10.1 where the same sysinfo shows:
- Derby Information
JRE - JDBC: J2SE 5.0 - JDBC 3.0
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.1.3.2 -
(426741)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.1.3.2
- (426741)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar]
10.1.3.2 - (426741)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar]
10.1.3.2 - (426741)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc.jar] 2.6 - (90)
[C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar]
2.6 - (90)
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ] V.Narayanan updated DERBY-700: -- Attachment: DERBY-700.diff DERBY-700.stat Hi, We could solve this problem by setting a System property before booting a database and checking for the property during subsequent boots. When the database is shutdown we set the property to false. For example when we boot a database named mydb then we set the property derby.dblock.mydb = true. Now during subsequent boots we could check for this system variable and if it is set to true throw an exception. During the shutdown of the database we set this variable to false. I tried an attempt along this line in the attached patch. I HAVE NOT run the patch with security manager enabled. The sample repro attached with this issue passes with this fix. Pls note that the patch is not for a commit but is just to represent what I have in mind as a solution, in the form of code. thanx Narayanan Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: http://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Assigned To: V.Narayanan Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-700.diff, DERBY-700.stat, DualBootRepro.java, DualBootRepro2.zip Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- 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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424850 ]
Kathey Marsden commented on DERBY-1516:
---
The new positive cases sound fine to me.
If I understand all you wrote, you are saying that getSubstring(pos,0) where
pos the length of the clob should throw an exception for now while spec
clarification is underway. Is that correct? If so, that sounds good to me as
it is always *much* easier to change an exception case to work in the future if
need be. What we want to avoid is a situation where something works and then
we have to throw an exception later to be compliant. Can you add negative
cases for this to make sure we are throwing an appropriate exception? Then I
think all the needed zero length cases will be covered.
Thanks
Kathey
Inconsistent behavior for getBytes and getSubString for embedded versus
network
---
Key: DERBY-1516
URL: http://issues.apache.org/jira/browse/DERBY-1516
Project: Derby
Issue Type: Bug
Components: JDBC
Reporter: Craig Russell
Assigned To: Craig Russell
Priority: Minor
Attachments: DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch
org.apache.derby.client.am.Clob.getSubString(pos, length) and
org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for
less than zero.
if ((pos = 0) || (length 0)) {
throw new SqlException(agent_.logWriter_, Invalid position
+ pos + or length + length);
But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and
org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less
than or equal to zero.
if (length = 0)
throw Util.generateCsSQLException(
SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
The specification does not disallow length of zero, so zero length should be
allowed. I believe that the implementation in org.apache.derby.client.am is
correct, and the implementation in org.apache.derby.impl.jdbc is incorrect.
--
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
Regression Test Failure! - TinderBox_Derby 427510 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 427510/2006-08-01 12:03:02 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 4686682 2 146.13% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-427510.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/427510.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/427510.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-244) with linux, depending on env setting $LANG and console encoding, some i18n tests fail
[ http://issues.apache.org/jira/browse/DERBY-244?page=comments#action_12424854 ] Rick Hillegas commented on DERBY-244: - I'm afraid I see diffs in these tests when run against jar files on Linux and jdk1.4: urlLocale messageLocale iepnegativetests_ES with linux, depending on env setting $LANG and console encoding, some i18n tests fail - Key: DERBY-244 URL: http://issues.apache.org/jira/browse/DERBY-244 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.1.1.0 Environment: Linux, with console.encoding *not* UTF-8 Reporter: Myrna van Lunteren Assigned To: Knut Anders Hatlen Priority: Minor Attachments: 244-2.diff, 244-2.stat, 244.diff, 244.stat The tests i18n/messageLocale.sql i18n/urlLocale.sql i18n/iepnegativetests_ES.sql will fail on Linux if $LANG and as a result, console.encoding is not set in the same way as when the test master was created. The behavior is that some characters are not seen as outside the ANSI range and are displayed as a ?. Result is as master when $LANG is en_US.UTF-8 But then ieptest.sql will fail which will with ibm142 which pass if $LANG is en_US. This needs some further analysis, so this description may need to be updated later. Whatever the solution is, will need to work for all situations. -- 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-1489) Provide ALTER TABLE DROP COLUMN functionality
[ http://issues.apache.org/jira/browse/DERBY-1489?page=comments#action_12424863 ] Rick Hillegas commented on DERBY-1489: -- Hi Bryan: Thanks for this great feature. The parser changes look good: thanks for cleaning up the LOOKAHEADs in alterTableAction(). 1) I agree that it would be good to see some tests verifying that privilege descriptors are cleaned up. 2) I'm curious about why ALTER TABLE DROP COLUMN CASCADE fails if a view mentions the column. From your comment in altertable.sql, it seems that this puzzles you too. It does look wrong to me. Provide ALTER TABLE DROP COLUMN functionality - Key: DERBY-1489 URL: http://issues.apache.org/jira/browse/DERBY-1489 Project: Derby Issue Type: New Feature Components: Documentation, SQL Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Bryan Pendleton Assigned To: Bryan Pendleton Fix For: 10.2.0.0 Attachments: dropColumn_2.diff Provide a way to drop a column from an existing table. Possible syntax would be: ALTER TABLE tablename DROP COLUMN columnname CASCADE / RESTRICT; Feature should properly handle columns which are used in constraints, views, triggers, indexes, etc. -- 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-1341) LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface
[ http://issues.apache.org/jira/browse/DERBY-1341?page=all ] Fernanda Pizzorno updated DERBY-1341: - Attachment: LobStreamTest.java I am planning to use similar stream to those implemented in the patch (derby-1341-blob-forreview.diff) for Derby-1560. I have written the attached test (LobStreamTest.java) to verify the implementation of input and output streams. You might be interested in using this test while working on the implementation of these streams. To be able to run the test, the class LOBStreamControl, its constructor and the getInputStream() and getOutputStream() methods must be public. LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface -- Key: DERBY-1341 URL: http://issues.apache.org/jira/browse/DERBY-1341 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.3.0.0, 10.1.2.4, 10.1.2.5 Environment: Windows 2000 Reporter: Keith McFarlane Assigned To: Anurag Shekhar Fix For: 10.2.0.0 Attachments: derby-1341-blob-forreview.diff, derby-1341.diff, LobStreamTest.java JDBC LOB . getBtypes methods are not implemented in any Derby version to date: there is a place-holder method that throws a SQLException reporting that the methods are not implemented. It would be excellent to have any efficient Derby implementation of the getBytes LOB methods that provide random-access to the binary // character content of database large objects. The specific context is implementing a Lucene Directory interface that stores indexing data (index files) and other binary data in a local encrypted Derby instance. A work around is to write an encrypted RandomAccessFile implementation as a file-sdystem buffer, perhaps writing to the database on closure. An efficient Derby implementation of LOB . getBytes would avoid this an make for a clean design. I can think of several reasons why random-access to LOBs would be valuable in a hostile client environment. -- 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-1252) Old clients with new server return wrong database metadata values for some methods
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik reassigned DERBY-1252:
Assignee: Dag H. Wanvik
Old clients with new server return wrong database metadata values for some
methods
--
Key: DERBY-1252
URL: http://issues.apache.org/jira/browse/DERBY-1252
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1,
10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
Reporter: Dag H. Wanvik
Assigned To: Dag H. Wanvik
Priority: Minor
Fix For: 10.2.0.0
With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
some metadata calls will return the wrong value for both the JCC and
the Derby clients:
deletesAreDetected(TYPE_SCROLL_INSENSITIVE) - true
updatedAreDetected(TYPE_SCROLL_INSENSITIVE) - true
ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
This happens because these values were changed for the 10.2 with
the addition of updatable scrollable insensitive result sets (DERBY-775),
combined with a weakness in the way the client and the server
cooperates to answer these metadata calls.
Presently, when the client application invokes these methods, the
results will be returned by the server without regard to the identity
of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
The values to be returned for the methods in question are based solely
on the values found in the file metadata_net.properties, which is part
of the server.
In general, some database metadata is dependent on the combination of
the capabilities in the client and the server and the returned values
should reflect this, which in general implies negotiating (down) to
values which are correct for the actual combination of client and
server.
--
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: Influencing the standards which govern Derby
I wanted to summarize where I think this discussion stands now: 1) SQL - Individuals can influence the SQL spec by renting cheap seats from ANSI for $500/year. See http://www.ansi.org/membership/overview/overview.aspx?menuid=2. 2) JDBC - Fortunately, the JDBC spec lead will continue to be a member of our community. In addition, individuals can join the JCP for free. See http://jcp.org/en/participation/membership. 3) DRDA - No-one has proposed a strategy for influencing DRDA. I have emailed my contacts at the DBIOP Consortium, the body which governs the DRDA spec. I asked them whether they would consider offering Derby a cheap seat like ANSI, a scholarship, or some other creative way to participate. I was told the following: 3a) The DBIOP Contortium doesn't offer cheap seats or scholarships. 3b) However, it might be possible for a Consortium member to act as Derby's sponsor, advocating our proposals provided that our submissionis were complete. So far this is just a possibility. I don't know how likely it is. Regards, -Rick Rick Hillegas wrote: I would like to understand how the community influences the standards which govern Derby: 1) SQL - I've been participating in Derby for a year now. Over the past year I don't recall any discussion about a need to change the SQL standard. We have proposed new language in rare cases not covered by the ANSI volumes. However, I don't recall any attempt to contact the SQL group and try to change their spec. Do we need to influence this spec and if so, how do we propose to do so? 2) JDBC - There has been substantial discussion about the upcoming JDBC4 spec.. Fortunately for us, the spec lead is a member of our community. In several cases he has taken our viewpoint back to the JDBC expert group and advocated our position. However, we don't know who will lead the expert group for JDBC5. How do we expect to influence the next rev of JDBC? 3) DRDA - Over the last year, I failed to get a Boolean datatype into the DRDA spec. This stemmed from the internal dynamics and pay-for-play nature of the spec's governing body, the DBIOP Consortium. How do we expect to influence the DRDA spec? If there's a general solution which covers all of these cases, that's great. If we handle each spec differently, that's fine too. I'd just like some discussion and guidance. Thanks, -Rick
[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-7a-clientborderfix.diff derby-1417-7a-clientborderfix.stat 'derby-1417-7a-clientborderfix.diff' fixes bugs in the client-side implementation. The bugs caused Derby to hang if the size of the data was the same as the internal buffer, and there was also a bug that could cause an ArrayIndexOutOfBoundException. Comments: 1) I have added more tests for ByteArrayCombinerStream, and also done some whitespace changes here. 2) Added comments to ByteArrayCombinerStream. 3) Made ByteArrayCombinerStream throw IllegalArgumentException for negative lengths and if there is not enough data for the length specified (detected in constructor). As this is an internal class, I hope this is acceptable. If not, I would like to know how these exeptional situations should be handled. I ran tests with Blob sizes of 1K, 32K, 65K, 10M, 100M and 2G with the client. Tests for 100M and 2G fails badly, and Derby hangs due to an OutOfMemoryError on the server. The situation is somewhat improved by the patch 'DERBY-1559.diff', but I still get ugly crashes, like broken communications pipe. I have not looked these problems. I ran the jdbc40 suite without failures. I will add more tests soon, but need to coordinate with other work (might add tests one of the several existing tests). The patch is ready for review/commit. 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.0.0 Reporter: Rick Hillegas Assigned To: Kristian Waagan Fix For: 10.2.0.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 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,
[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: --- Derby Info: [Patch Available] 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.0.0 Reporter: Rick Hillegas Assigned To: Kristian Waagan Fix For: 10.2.0.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 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424887 ]
Craig Russell commented on DERBY-1516:
--
Thanks for the feedback. I'll make some positive and negative test cases and
update the patch.
Yes, I'm suggesting that we follow the java.lang.String specification and allow
for zero-length getSubString only if the position is legal. This is so there's
no special if (length == 0) { // ignore position for 0-length ...}. It actually
simplifies development.
Inconsistent behavior for getBytes and getSubString for embedded versus
network
---
Key: DERBY-1516
URL: http://issues.apache.org/jira/browse/DERBY-1516
Project: Derby
Issue Type: Bug
Components: JDBC
Reporter: Craig Russell
Assigned To: Craig Russell
Priority: Minor
Attachments: DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch
org.apache.derby.client.am.Clob.getSubString(pos, length) and
org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for
less than zero.
if ((pos = 0) || (length 0)) {
throw new SqlException(agent_.logWriter_, Invalid position
+ pos + or length + length);
But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and
org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less
than or equal to zero.
if (length = 0)
throw Util.generateCsSQLException(
SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
The specification does not disallow length of zero, so zero length should be
allowed. I believe that the implementation in org.apache.derby.client.am is
correct, and the implementation in org.apache.derby.impl.jdbc is incorrect.
--
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-1620) SQL CASE statement returns ERROR 42X89 when including NULL as a return value
SQL CASE statement returns ERROR 42X89 when including NULL as a return value Key: DERBY-1620 URL: http://issues.apache.org/jira/browse/DERBY-1620 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1 Environment: Windows XP Reporter: John Peterson This bug appears to be related to the DERBY-7 bug (NULLIF() function). When NULL is used during a CASE statement, Derby requires the NULL to be CAST to the appropriate type. This does not appear to meet the SQL 2003 Standard for the Case Expression (see attached Word document). See the attached Word document to view the Derby Community Discussion about this issue. See the attached .TXT to view the SYSINFO and to see an example of the steps to reproduce using IJ. Steps to Reproduce: ijvalues case when 1=2 then 3 else NULL end; ERROR 42X89: Types 'INTEGER' and 'CHAR' are not type compatible. Neither type is assignable to the other type. Current Workaround: ijvalues case when 1=2 then 3 else cast(NULL as INT) 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-1616) Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException
[ http://issues.apache.org/jira/browse/DERBY-1616?page=comments#action_12424893 ] Rick Hillegas commented on DERBY-1616: -- One small amendment: I'm aware of one more JDBC4 interface change (DERBY-1530). I expect the interface change will turn up in the Mustang beta around the time we cut the 10.2 branch. Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException - Key: DERBY-1616 URL: http://issues.apache.org/jira/browse/DERBY-1616 Project: Derby Issue Type: Bug Affects Versions: 10.2.0.0 Environment: jdk16 /windows. Reporter: Sunitha Kambhampati Fix For: 10.2.0.0 Attachments: derbyall_report.txt jdk16 derbyall derbyall: 19 failures derbyall/derbyall.fail:lang/compressTable.sql derbyall/derbyall.fail:lang/nestedCommit.sql derbyall/derbyall.fail:lang/outparams.java derbyall/derbyall.fail:lang/procedure.java derbyall/derbyall.fail:lang/procedureInTrigger.sql derbyall/derbyall.fail:tools/importExportThruIJ.sql derbyall/derbyall.fail:tools/ieptests.sql derbyall/derbyall.fail:tools/iepnegativetests.sql derbyall/derbyall.fail:jdbcapi/statementJdbc20.java derbyall/derbyall.fail:jdbcapi/statementJdbc30.java derbyall/derbyall.fail:jdbcapi/parameterMapping.java derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/ClosedObjectTest.junit derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/UnsupportedVetter.junit derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/VerifySignatures.junit derbyall/encryptionAll/encryption.fail:stress/stress.multi derbyall/encryptionAll/storemats.fail:store/streamingColumn.java derbyall/storeall/storeall.fail:store/TransactionTable.sql derbyall/storeall/storemats.fail:store/streamingColumn.java -- 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-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not ta
[
http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12424892 ]
Tomohito Nakayama commented on DERBY-1610:
--
I surveyed execution of Network Server with jdb when TestNullChar.java was
executed.
In both of updateStreamAsNull and setNull, type information at server side was
as next.
DRDAConnThread_3[1] dump pmeta.types[0].typeId.baseTypeId
pmeta.types[0].typeId.baseTypeId = {
SQLTypeName: CHAR
JDBCTypeId: 1
formatId: 17
wrapperTypeFormatId: 5
}
It is very questionable that type is regarded as char when InputStream was
passed.
Engine take it as type compatibility error to update column typed as CHAR to
value passed via setBinaryStream(null), though Network Client and Network
Server does not take it as error.
Key: DERBY-1610
URL: http://issues.apache.org/jira/browse/DERBY-1610
Project: Derby
Issue Type: Bug
Components: Network Server, Network Client
Reporter: Tomohito Nakayama
Assigned To: Tomohito Nakayama
Attachments: TestNullChar.java
There exists difference between Engine and Network Client/Engine around type
compatibility judgement in character typed column when null value was passed
as InputStream.
--
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-1620) SQL CASE statement returns ERROR 42X89 when including NULL as a return value
[ http://issues.apache.org/jira/browse/DERBY-1620?page=all ] John Peterson updated DERBY-1620: - Attachment: SQL2003_Standard_Case_Expression.doc Derby_Community_Discussion.doc sysinfo_and_example.txt These attachments are the SQL 2003 Standard for the Case Expression, the Derby Community Discussion about this issue, and the SysInfo along with an example of the Steps to Reproduce. SQL CASE statement returns ERROR 42X89 when including NULL as a return value Key: DERBY-1620 URL: http://issues.apache.org/jira/browse/DERBY-1620 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1 Environment: Windows XP Reporter: John Peterson Attachments: Derby_Community_Discussion.doc, SQL2003_Standard_Case_Expression.doc, sysinfo_and_example.txt This bug appears to be related to the DERBY-7 bug (NULLIF() function). When NULL is used during a CASE statement, Derby requires the NULL to be CAST to the appropriate type. This does not appear to meet the SQL 2003 Standard for the Case Expression (see attached Word document). See the attached Word document to view the Derby Community Discussion about this issue. See the attached .TXT to view the SYSINFO and to see an example of the steps to reproduce using IJ. Steps to Reproduce: ijvalues case when 1=2 then 3 else NULL end; ERROR 42X89: Types 'INTEGER' and 'CHAR' are not type compatible. Neither type is assignable to the other type. Current Workaround: ijvalues case when 1=2 then 3 else cast(NULL as INT) 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
Re: [jira] Commented: (DERBY-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does no
Hello Dag. I linked it :) Best regards. Dag H. Wanvik wrote: Hi, You may want to link this issue to DERBY-310. Thanks, Dag -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
[jira] Commented: (DERBY-1417) Add new, lengthless overloads to the streaming api
[ http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12424900 ] Rick Hillegas commented on DERBY-1417: -- Thanks for these bug fixes, Kristian. My only questions about the IllegalArgumentException would be: a) How would a user trip across this? b) What would the user see? Thanks for including a test case for this exception. 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.0.0 Reporter: Rick Hillegas Assigned To: Kristian Waagan Fix For: 10.2.0.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 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1608) Execution of builtin functions by a user who is not the owner of system schemas gives NPE when authentication and SQL authorization are on.
[ http://issues.apache.org/jira/browse/DERBY-1608?page=all ]
Deepa Remesh closed DERBY-1608.
---
Verified fix by running the repros and the modified upgrade test. Thanks
Satheesh.
Execution of builtin functions by a user who is not the owner of system
schemas gives NPE when authentication and SQL authorization are on.
---
Key: DERBY-1608
URL: http://issues.apache.org/jira/browse/DERBY-1608
Project: Derby
Issue Type: Bug
Components: SQL
Reporter: Deepa Remesh
Assigned To: Satheesh Bandaram
Fix For: 10.2.0.0
1. Create a database in 10.1
2. Full upgrade to 10.2 - Booting using 10.2 jars by specifying
upgrade=true in the connection URL.
3. Execute a function e.g: VALUES { fn ACOS(0.0707) }. This passes as
expected.
4. Set database property derby.database.sqlAuthorization=true.
5. Shutdown and reconnect to database for the property to take effect.
6. Re-execute the function. This gives NPE.
Repro using ij:
Steps using 10.1 jar:
ij version 10.1
ij connect 'jdbc:derby:old_db;create=true';
ij exit;
Steps using 10.2 jar:
ij version 10.2
ij connect 'jdbc:derby:old_db;upgrade=true';
ij VALUES { fn ACOS(0.0707) };
1
--
1.5000372950430991
1 row selected
ij call
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.sqlAuthorization',
'true');
0 rows inserted/updated/deleted
ij connect 'jdbc:derby:old_db;shutdown=true';
ERROR 08006: Database 'old_db' shutdown.
ij connect 'jdbc:derby:old_db';
ij(CONNECTION1) VALUES { fn ACOS(0.0707) };
ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
ij(CONNECTION1)
Stack trace of failure:
ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
java.lang.NullPointerException
at
org.apache.derby.iapi.sql.dictionary.RoutinePermsDescriptor.init(RoutinePermsDescriptor
.java:54)
at
org.apache.derby.iapi.sql.dictionary.RoutinePermsDescriptor.init(RoutinePermsDescriptor
.java:62)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getRoutinePermissions(DataDictionary
Impl.java:9902)
at
org.apache.derby.iapi.sql.dictionary.StatementRoutinePermission.check(StatementRoutinePer
mission.java:55)
at
org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(GenericAuthorizer.java:157)
at
org.apache.derby.exe.ac6b91c056x010cxb687x3eb7x0012d1c00.fillResultSet(Unknown
Source
)
at
org.apache.derby.exe.ac6b91c056x010cxb687x3eb7x0012d1c00.execute(Unknown
Source)
at
org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:32
6)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:
355)
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:312)
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] Updated: (DERBY-1521) Upgrade test needs to be enhanced to test grant revoke
[ http://issues.apache.org/jira/browse/DERBY-1521?page=all ] Deepa Remesh updated DERBY-1521: Attachment: d1521-patch2-v1.diff d1521-patch2-v1.status Attaching patch 'd1521-patch2-v1.diff' which is same as the draft patch 'd1521-patch2-draft.diff'. Only difference is the new patch is based on later svn revision. With this patch, upgrade test passes as DERBY-1608 has been fixed by Satheesh. Please review/commit this patch. Thanks. Upgrade test needs to be enhanced to test grant revoke -- Key: DERBY-1521 URL: http://issues.apache.org/jira/browse/DERBY-1521 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Deepa Remesh Fix For: 10.2.0.0 Attachments: d1521-patch1-v1.diff, d1521-patch1-v1.status, d1521-patch2-draft.diff, d1521-patch2-v1.diff, d1521-patch2-v1.status Grant Revoke is one of the features targeted for 10.2 Release. The upgrade test should be modified to test this feature with various upgrade scenarios to make sure everything works fine. -- 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-1341) LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface
[ http://issues.apache.org/jira/browse/DERBY-1341?page=comments#action_12424910 ] Anurag Shekhar commented on DERBY-1341: --- Thanks Fernanda for the test. I will prefer to keep LOBStreamControl's scope at the package. Let me try to modify the test so that it can still test the Streams. I am thinking of creating new blob using connection.createBlob and getting the stream from this blob to use in the test class you have written. LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface -- Key: DERBY-1341 URL: http://issues.apache.org/jira/browse/DERBY-1341 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.3.0.0, 10.1.2.4, 10.1.2.5 Environment: Windows 2000 Reporter: Keith McFarlane Assigned To: Anurag Shekhar Fix For: 10.2.0.0 Attachments: derby-1341-blob-forreview.diff, derby-1341.diff, LobStreamTest.java JDBC LOB . getBtypes methods are not implemented in any Derby version to date: there is a place-holder method that throws a SQLException reporting that the methods are not implemented. It would be excellent to have any efficient Derby implementation of the getBytes LOB methods that provide random-access to the binary // character content of database large objects. The specific context is implementing a Lucene Directory interface that stores indexing data (index files) and other binary data in a local encrypted Derby instance. A work around is to write an encrypted RandomAccessFile implementation as a file-sdystem buffer, perhaps writing to the database on closure. An efficient Derby implementation of LOB . getBytes would avoid this an make for a clean design. I can think of several reasons why random-access to LOBs would be valuable in a hostile client environment. -- 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
GRANT/REVOKE doc review - comments needed for DERBY-1057
Hi - I posted a doc review for GRANT/REVOKE and would like to post the patch later this week. Please take a few minutes to review the updates to the Reference Manual and the Developers Guide. Here is the link - https://issues.apache.org/jira/browse/DERBY-1057 Thanks! -- Laura Stewart
[jira] Commented: (DERBY-1539) As per the functional spec attached to DERBY-1330, a trigger should be dropped when a privilege required by the trigger is revoked.
[ http://issues.apache.org/jira/browse/DERBY-1539?page=comments#action_12424913 ] Daniel John Debrunner commented on DERBY-1539: -- On the trigger re-compile issue it seems there is a serious problem currently (regardless of grant/revoke issues) with triggers. This may need to be fixed before modifying the trigger -revoke interation any more. I wonder if you can make progress on the view constraint dropping before completing the trigger? At least get them in to a similar state as triggers where a revoke wil drop the object, even if it drops it in too many situations. As per the functional spec attached to DERBY-1330, a trigger should be dropped when a privilege required by the trigger is revoked. --- Key: DERBY-1539 URL: http://issues.apache.org/jira/browse/DERBY-1539 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Mamta A. Satoor Fix For: 10.2.0.0 Attachments: DERBY1539V1hashCodeEqualsDiff.txt, DERBY1539V1hashCodeEqualsStat.txt, DERBY1539V2diffDropTriggerOnRevoke.txt, DERBY1539V2statDropTriggerOnRevoke.txt, DERBY1539V3diffDropTriggerOnRevoke.txt, DERBY1539V3statDropTriggerOnRevoke.txt, DERBY1539V4diffDropTriggerOnRevoke.txt, DERBY1539V4diffDropTriggerOnRevokeRequiredPrivilege.txt, DERBY1539V4statDropTriggerOnRevokeRequiredPrivilege.txt A trigger tracks its privileges requirements using Derby's Dependency Manager. If any one of those required privileges are revoked, the trigger should be dropped automatically. I am just creating a new jira entry here so it is easier to track sub items of DERBY-1330. Will link this Jira entry to DERBY-1330. -- 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-1621) Trigger action statement is not recompile when there is a change that would affect it.
Trigger action statement is not recompile when there is a change that would affect it. -- Key: DERBY-1621 URL: http://issues.apache.org/jira/browse/DERBY-1621 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Priority: Critical Fix For: 10.2.0.0 A trigger action statement, such as an INSERT statement is not recompiled when there is some DDL change on the underlying table, such as a CREATE INDEX. In the example below a unique index is added to the table (t2) inserted into by the trigger's action statement. When the tirgger fires it does not raise any error (should raise a unique constraint violated error) and does not insert the value into the index. A select from t2 does not show the additional rows in t2 as it is performing an index scan, once the index is dropped the rows appear to the select. ij version 10.2 ij connect 'jdbc:derby:cs;create=true'; ij create table t (i int); 0 rows inserted/updated/deleted ij create table t2 (i int); 0 rows inserted/updated/deleted ij create trigger tt after insert on t for each statement mode db2sql insert into t2 values 1; 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij create unique index tu on t2(i); 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij drop index tu; 0 rows inserted/updated/deleted ij select * from t2; I --- 1 1 1 3 rows selected -- 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: Influencing the standards which govern Derby
Rick Hillegas wrote: I wanted to summarize where I think this discussion stands now: ... 2) JDBC - Fortunately, the JDBC spec lead will continue to be a member of our community. In addition, individuals can join the JCP for free. See http://jcp.org/en/participation/membership. Individuals can also get involved inside Apache -- details are at http://www.apache.org/jcp/ . -jean
[jira] Commented: (DERBY-939) NullPointerException at ResultSet.close() time for simple query using UNION and INTERSECT
[ http://issues.apache.org/jira/browse/DERBY-939?page=comments#action_12424921 ] David Van Couvering commented on DERBY-939: --- Has anyone besides Yip run derbyall on this patch yet? If it passes derbyall, I'd be happy to check it in. If I need to run derbyall, that will take me some more time... NullPointerException at ResultSet.close() time for simple query using UNION and INTERSECT - Key: DERBY-939 URL: http://issues.apache.org/jira/browse/DERBY-939 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0, 10.1.3.0 Environment: Embedded and server modes, with derby.language.logQueryPlan=true Reporter: A B Assigned To: Yip Ng Priority: Minor Attachments: derby939trunkdiffpatch1.txt, derby939trunkdiffpatch2.txt, derby939trunkstatpatch1.txt, derby939trunkstatpatch2.txt If I set derby.language.logQueryPlan to true and then attempt to execute the following simple query using UNION and INTERSECT, Derby will return the correct results and then, _after_ returning the results, will throw a NullPointerException. This error also occurs for 10.1. To reproduce: java -Dderby.language.logQueryPlan=true org.apache.derby.tools.ij and then do: create table t1 (i int); create table t2 (j int); create table t3 (a int); ij select i from t1 union (select j from t2 intersect select a from t3); 1 --- 0 rows selected ERROR XJ001: Java exception: ': java.lang.NullPointerException'. If I add data, the query will return the correct results, but then throw the NPE. insert into t1 values 1, 2, 3, 4, 5; insert into t2 values 2, 4, 6, 8, 10; insert into t3 values 2, 3, 4; ij select i from t1 union (select j from t2 intersect select a from t3); 1 --- 1 2 3 4 5 5 rows selected ERROR XJ001: Java exception: ': java.lang.NullPointerException'. The embedded and client stack traces are shown below. Both suggest that the problem occurs during the close of the result set. -- Embedded -- java.lang.NullPointerException at org.apache.derby.impl.sql.execute.rts.RealUnionResultSetStatistics.getStatementExecutionPlanText(RealUnionResultSetStatistics.java:107) at org.apache.derby.impl.sql.execute.rts.RealSortStatistics.getStatementExecutionPlanText(RealSortStatistics.java:124) at org.apache.derby.impl.sql.execute.rts.RunTimeStatisticsImpl.getStatementExecutionPlanText(RunTimeStatisticsImpl.java:293) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.finishAndRTS(BasicNoPutResultSetImpl.java:633) at org.apache.derby.impl.sql.execute.SortResultSet.finish(SortResultSet.java:479) at org.apache.derby.impl.jdbc.EmbedResultSet.close(EmbedResultSet.java:533) at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:272) at org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:260) at org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:381) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:434) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:203) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) -- Client -- ERROR (no SQLState): actual code point, 4692 does not match expected code point, 9224 java.sql.SQLException: actual code point, 4692 does not match expected code point, 9224 at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:280) at org.apache.derby.client.am.ResultSet.close(ResultSet.java:412) at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:272) at org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:260) at org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:381) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:434) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:203) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) Caused by: org.apache.derby.client.am.DisconnectException: actual code point, 4692 does not match ex pected code point, 9224 at org.apache.derby.client.net.Reply.zThrowSyntaxError(Reply.java:1157) at
[jira] Updated: (DERBY-1619) Sysinfo in 10.2 shows multiple entries if the derby jars reside in a directory with spaces in its name
[ http://issues.apache.org/jira/browse/DERBY-1619?page=all ] Andrew McIntyre updated DERBY-1619: --- Attachment: derby-1619-v2.diff Thanks, John. There is a general solution for this problem: java.net.URLDecoder. :-) Attaching patch -v2, which uses URLDecoder. This should take care of all similar encoding problems. Sysinfo in 10.2 shows multiple entries if the derby jars reside in a directory with spaces in its name --- Key: DERBY-1619 URL: http://issues.apache.org/jira/browse/DERBY-1619 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.2.0.0 Environment: Windows XP, jdk 1.5 Reporter: Rajesh Kartha Assigned To: Andrew McIntyre Fix For: 10.2.0.0 Attachments: derby-1619-v1.diff, derby-1619-v2.diff For the Derby jars residing in C:\Documents and Settings\Administrator\TEMP DIR\lib, the sysinfo shows: - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derby.jar] 10.2.0.5 alpha - (426734) [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbytools.jar] 10.2.0.5 alpha - (426734) [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbynet.jar] 10.2.0.5 alpha - (426734) [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbyclient.jar] 10.2.0.5 alpha - (426734) [C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.2.0.5 alpha - (426734) [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.2.0.5 alpha - (426734) [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar] 10.2.0.5 alpha - (426734) [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar] 10.2.0.5 alpha - (426734) [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\db2jcc.jar] 2.6 - (90) [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar] 2.6 - (90) -- This is a regression from 10.1 where the same sysinfo shows: - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.1.3.2 - (426741) [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.1.3.2 - (426741) [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar] 10.1.3.2 - (426741) [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar] 10.1.3.2 - (426741) [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc.jar] 2.6 - (90) [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar] 2.6 - (90) -- -- 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-1584) store/encryptionKey_jar.sql fails on Cygwin
[ http://issues.apache.org/jira/browse/DERBY-1584?page=comments#action_12424925 ] Sunitha Kambhampati commented on DERBY-1584: Thanks Rick for trying this test out on cygwin in your environment.I looked at Ole's reports and this test still fails on cygwin/jdk15 . Not sure what is so special about the setup there. store/encryptionKey_jar.sql fails on Cygwin --- Key: DERBY-1584 URL: http://issues.apache.org/jira/browse/DERBY-1584 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.2.0.0 Environment: Cygwin, Sun JDK 1.5 Reporter: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: 424402.zip, sane.zip http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/424402-derbyall_diff.txt * Diff file derbyall/encryptionAll/encryptionAll/encryptionKey_jar.diff *** Start: encryptionKey_jar jdk1.5.0_04 encryptionAll:encryptionAll 2006-07-22 01:35:47 *** 39,50d38 ij(DB1) select * from t1 order by a; A --- 1 2 3 4 5 ij(DB1) connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij(DB1) -- NEGATIVE CASE: Test with wrong encryption key. This should fail. connect 'jdbc:derby:jar:(ina.jar)db1;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB1; 52 del ERROR XBCXK: The given encryption key does not match the encryption key used when creating the database. Please ensure that you are using the correct encryption key and try again. 53 del ij(DB1) disconnect; 53a40,50 ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij select * from t1 order by a; IJ ERROR: Unable to establish connection ij connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij -- NEGATIVE CASE: Test with wrong encryption key. This should fail. connect 'jdbc:derby:jar:(ina.jar)db1;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB1; ERROR XJ040: Failed to start database 'jar:(ina.jar)db1', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij disconnect; IJ ERROR: Unable to establish connection 58 del ij(DB1) connect 'jdbc:derby:;shutdown=true'; 58a55,57 ERROR XJ040: Failed to start database 'jar:(ina.jar)db1', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij connect 'jdbc:derby:;shutdown=true'; 60 del ij(DB1) -- connect to database in jar file using classpath subprotocol. 60a59 ij -- connect to database in jar file using classpath subprotocol. 64 del ij(DB1) -- create a class loader for this current thread 64a63 ij -- create a class loader for this current thread 76,87d74 ij(DB2CL) select * from t1 order by a; A --- 1 2 3 4 5 ij(DB2CL) connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij(DB2CL) -- try with wrong encryption key, this should fail. connect 'jdbc:derby:classpath:db2;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB2CL; 89 del ERROR XBCXK: The given encryption key does not match the encryption key used when creating the database. Please ensure that you are using the correct encryption key and try again. 90 del ij(DB2CL) exit; 90 add ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.CPStorageFactory registered for identifier classpath. ij select * from t1 order by a; IJ ERROR: Unable to establish connection ij connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij -- try with wrong encryption key, this should fail. connect 'jdbc:derby:classpath:db2;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB2CL; ERROR XJ040: Failed to start database 'classpath:db2', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.CPStorageFactory registered for identifier classpath. ij exit; Test Failed. *** End: encryptionKey_jar jdk1.5.0_04 encryptionAll:encryptionAll 2006-07-22 01:36:14 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the
[jira] Commented: (DERBY-1620) SQL CASE statement returns ERROR 42X89 when including NULL as a return value
[ http://issues.apache.org/jira/browse/DERBY-1620?page=comments#action_12424927 ] Jean T. Anderson commented on DERBY-1620: - For any who don't have Word, the start for the discussion in Derby_Community_Discussion.doc can be viewed at these locations: ASF archives: http://mail-archives.apache.org/mod_mbox/db-derby-user/200607.mbox/[EMAIL PROTECTED] http://tinyurl.com/lceff Nabble: http://www.nabble.com/ERROR-42X89%3A-Types-%27INTEGER%27-and-%27CHAR%27-are-not-type-compatible.-Neither-type-is-assignable-to-the-other-type.-p5527265.html http://tinyurl.com/oomep SQL CASE statement returns ERROR 42X89 when including NULL as a return value Key: DERBY-1620 URL: http://issues.apache.org/jira/browse/DERBY-1620 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1 Environment: Windows XP Reporter: John Peterson Attachments: Derby_Community_Discussion.doc, SQL2003_Standard_Case_Expression.doc, sysinfo_and_example.txt This bug appears to be related to the DERBY-7 bug (NULLIF() function). When NULL is used during a CASE statement, Derby requires the NULL to be CAST to the appropriate type. This does not appear to meet the SQL 2003 Standard for the Case Expression (see attached Word document). See the attached Word document to view the Derby Community Discussion about this issue. See the attached .TXT to view the SYSINFO and to see an example of the steps to reproduce using IJ. Steps to Reproduce: ijvalues case when 1=2 then 3 else NULL end; ERROR 42X89: Types 'INTEGER' and 'CHAR' are not type compatible. Neither type is assignable to the other type. Current Workaround: ijvalues case when 1=2 then 3 else cast(NULL as INT) 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] Updated: (DERBY-1584) store/encryptionKey_jar.sql and lang/dcl.sql fails on Cygwin
[ http://issues.apache.org/jira/browse/DERBY-1584?page=all ] Sunitha Kambhampati updated DERBY-1584: --- Summary: store/encryptionKey_jar.sql and lang/dcl.sql fails on Cygwin (was: store/encryptionKey_jar.sql fails on Cygwin) Updating the summary. The error seen in this failure is similar to the error seen in lang/dcl.sql. Both these tests seem to so far fail only on Ole's test machines/cygwin/jdk15. store/encryptionKey_jar.sql and lang/dcl.sql fails on Cygwin Key: DERBY-1584 URL: http://issues.apache.org/jira/browse/DERBY-1584 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.2.0.0 Environment: Cygwin, Sun JDK 1.5 Reporter: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: 424402.zip, sane.zip http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/424402-derbyall_diff.txt * Diff file derbyall/encryptionAll/encryptionAll/encryptionKey_jar.diff *** Start: encryptionKey_jar jdk1.5.0_04 encryptionAll:encryptionAll 2006-07-22 01:35:47 *** 39,50d38 ij(DB1) select * from t1 order by a; A --- 1 2 3 4 5 ij(DB1) connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij(DB1) -- NEGATIVE CASE: Test with wrong encryption key. This should fail. connect 'jdbc:derby:jar:(ina.jar)db1;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB1; 52 del ERROR XBCXK: The given encryption key does not match the encryption key used when creating the database. Please ensure that you are using the correct encryption key and try again. 53 del ij(DB1) disconnect; 53a40,50 ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij select * from t1 order by a; IJ ERROR: Unable to establish connection ij connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij -- NEGATIVE CASE: Test with wrong encryption key. This should fail. connect 'jdbc:derby:jar:(ina.jar)db1;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB1; ERROR XJ040: Failed to start database 'jar:(ina.jar)db1', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij disconnect; IJ ERROR: Unable to establish connection 58 del ij(DB1) connect 'jdbc:derby:;shutdown=true'; 58a55,57 ERROR XJ040: Failed to start database 'jar:(ina.jar)db1', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij connect 'jdbc:derby:;shutdown=true'; 60 del ij(DB1) -- connect to database in jar file using classpath subprotocol. 60a59 ij -- connect to database in jar file using classpath subprotocol. 64 del ij(DB1) -- create a class loader for this current thread 64a63 ij -- create a class loader for this current thread 76,87d74 ij(DB2CL) select * from t1 order by a; A --- 1 2 3 4 5 ij(DB2CL) connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij(DB2CL) -- try with wrong encryption key, this should fail. connect 'jdbc:derby:classpath:db2;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB2CL; 89 del ERROR XBCXK: The given encryption key does not match the encryption key used when creating the database. Please ensure that you are using the correct encryption key and try again. 90 del ij(DB2CL) exit; 90 add ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.CPStorageFactory registered for identifier classpath. ij select * from t1 order by a; IJ ERROR: Unable to establish connection ij connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij -- try with wrong encryption key, this should fail. connect 'jdbc:derby:classpath:db2;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB2CL; ERROR XJ040: Failed to start database 'classpath:db2', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.CPStorageFactory registered for identifier classpath. ij exit; Test Failed. *** End: encryptionKey_jar jdk1.5.0_04 encryptionAll:encryptionAll 2006-07-22 01:36:14 *** -- This
[jira] Commented: (DERBY-1621) Trigger action statement is not recompile when there is a change that would affect it.
[ http://issues.apache.org/jira/browse/DERBY-1621?page=comments#action_12424931 ] Mamta A. Satoor commented on DERBY-1621: While on the topic of recompilation, I think there might be an issue with views as well. I don't see any code in ViewDescriptor invalidation related methods where the view gets recompiled. May be it is being done somewhere else but I wanted to raise the possible issue. If there indeed is a problem, we can open another Jira entry for it if required. Trigger action statement is not recompile when there is a change that would affect it. -- Key: DERBY-1621 URL: http://issues.apache.org/jira/browse/DERBY-1621 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Priority: Critical Fix For: 10.2.0.0 A trigger action statement, such as an INSERT statement is not recompiled when there is some DDL change on the underlying table, such as a CREATE INDEX. In the example below a unique index is added to the table (t2) inserted into by the trigger's action statement. When the tirgger fires it does not raise any error (should raise a unique constraint violated error) and does not insert the value into the index. A select from t2 does not show the additional rows in t2 as it is performing an index scan, once the index is dropped the rows appear to the select. ij version 10.2 ij connect 'jdbc:derby:cs;create=true'; ij create table t (i int); 0 rows inserted/updated/deleted ij create table t2 (i int); 0 rows inserted/updated/deleted ij create trigger tt after insert on t for each statement mode db2sql insert into t2 values 1; 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij create unique index tu on t2(i); 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij drop index tu; 0 rows inserted/updated/deleted ij select * from t2; I --- 1 1 1 3 rows selected -- 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-1530) DatabaseMetaData.getFunctionParameters() changing name to getFunctionColumns()
[ http://issues.apache.org/jira/browse/DERBY-1530?page=all ] Rick Hillegas reassigned DERBY-1530: Assignee: Rick Hillegas DatabaseMetaData.getFunctionParameters() changing name to getFunctionColumns() -- Key: DERBY-1530 URL: http://issues.apache.org/jira/browse/DERBY-1530 Project: Derby Issue Type: New Feature Components: JDBC Affects Versions: 10.2.0.0 Reporter: Rick Hillegas Assigned To: Rick Hillegas Fix For: 10.2.0.0 The JDBC4 expert group has made the following changes to their spec: DatabaseMetaData.getFunctionParameters() is changing name to getFunctionColumns() The DatabaseMetaData.functionParameter* constants are changing name to functionColumn* -- 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-1577) DatabaseMetaData.getIndexInfo() returns internal names
[ http://issues.apache.org/jira/browse/DERBY-1577?page=comments#action_12424942 ] Kathey Marsden commented on DERBY-1577: --- I think that the name of the backing index created is in fact different than the primary key, so I think it is correct that getIndexInfo() returns the generated index name.Is it really a bug? If you need the primary key and the index name to match, I wonder if RENAME INDEX might help: http://db.apache.org/derby/docs/10.1/ref/rrefsqlj95598.html DatabaseMetaData.getIndexInfo() returns internal names -- Key: DERBY-1577 URL: http://issues.apache.org/jira/browse/DERBY-1577 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.3.1 Environment: Windows 2003 Server Reporter: Jorg Janke Problem: - We inquire the meta data of the database and then dynamically update the database to its target date (e.g. add/modify tables, columns, indexes, constraints, ...) via (standard) DDL. When requesting the indexes for a table, we get the internal name, not the index name. When (re-) the submitting the DDL ALTER TABLE AD_ACCESSLOG ADD CONSTRAINT AD_ACCESSLOG_KEY PRIMARY KEY (AD_ACCESSLOG_ID) I get the error message Constraints 'AD_ACCESSLOG_KEY' and 'AD_ACCESSLOG_KEY' have the same set of columns, which is not allowed. Technical Description - Problem is that the Derby implementation of DatabaseMetaData.getIndexInfo() returns the internal (conglomerate) name rather then the real name of the index. I checked - in org.apache.derby.client.am.DatabaseMetaData.getIndexInfoX(..) you call the function SYSIBM.SQLSTATISTICS(?,?,?,?,?,?) - which returns the wrong data. Results from getIndexInfo(..) 0: TABLE_CAT=, TABLE_SCHEM=COMPIERE, TABLE_NAME=AD_ACCESSLOG, NON_UNIQUE=0, INDEX_QUALIFIER=, INDEX_NAME=SQL060709062929330, TYPE=3, ORDINAL_POSITION=1, COLUMN_NAME=AD_ACCESSLOG_ID, ASC_OR_DESC=A, CARDINALITY=null, PAGES=null, FILTER_CONDITION=null 1: TABLE_CAT=, TABLE_SCHEM=COMPIERE, TABLE_NAME=AD_ACCESSLOG, NON_UNIQUE=1, INDEX_QUALIFIER=, INDEX_NAME=SQL060716064852400, TYPE=3, ORDINAL_POSITION=1, COLUMN_NAME=AD_COLUMN_ID, ASC_OR_DESC=A, CARDINALITY=null, PAGES=null, FILTER_CONDITION=null Results from getImportedKeys(..) 0: PKTABLE_CAT=, PKTABLE_SCHEM=COMPIERE, PKTABLE_NAME=AD_COLUMN, PKCOLUMN_NAME=AD_COLUMN_ID, FKTABLE_CAT=, FKTABLE_SCHEM=COMPIERE, FKTABLE_NAME=AD_ACCESSLOG, FKCOLUMN_NAME=AD_COLUMN_ID, KEY_SEQ=1, UPDATE_RULE=3, DELETE_RULE=0, FK_NAME=ADCOLUMN_ADACCESSLOG, PK_NAME=AD_COLUMN_KEY, DEFERRABILITY=7 The problem would be solved, if in addition to the (internal type 3) index info you would provide the index type 1/2 info with the resuly of 0: .. INDEX_NAME=AD_ACCESSLOG_KEY, TYPE=1, ORDINAL_POSITION=1, COLUMN_NAME=AD_ACCESSLOG_ID, ASC_OR_DESC=A, CARDINALITY=null, PAGES=null, FILTER_CONDITION=null 1: .. INDEX_NAME=ADCOLUMN_ADACCESSLOG, TYPE=3, ORDINAL_POSITION=1, COLUMN_NAME=AD_COLUMN_ID, ASC_OR_DESC=A, CARDINALITY=null, PAGES=null, FILTER_CONDITION=null The original table definition is: CREATE TABLE AD_ACCESSLOG ( AD_ACCESSLOG_ID DECIMAL(10,0) NOT NULL, AD_CLIENT_IDDECIMAL(10,0) NOT NULL, AD_ORG_ID DECIMAL(10,0) NOT NULL, ISACTIVECHAR(1)DEFAULT 'Y' NOT NULL, CREATED TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, CREATEDBY DECIMAL(10,0) NOT NULL, UPDATED TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, UPDATEDBY DECIMAL(10,0) NOT NULL, AD_TABLE_ID DECIMAL(10,0) NULL, AD_COLUMN_IDDECIMAL(10,0) NULL, RECORD_ID DECIMAL(10,0) NULL, CONSTRAINT AD_ACCESSLOG_KEY PRIMARY KEY (AD_ACCESSLOG_ID), CONSTRAINT ADCOLUMN_ADACCESSLOG FOREIGN KEY (AD_COLUMN_ID) REFERENCES AD_COLUMN (AD_COLUMN_ID) ) --- Note that you create an index for a constraint - that is fine, but it would be helpful to again not get the internal name, but the external. Index 'SQL060716064852400' was created to enforce constraint 'ADCOLUMN_ADACCESSLOG'. It can only be dropped by dropping the constraint. - DROP INDEX SQL060716064852400 --- Help requested: --- If you please could fix it and tell me if I could find/update/fix the function SYSIBM.SQLSTATISTICS. -- 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-700) Derby does not prevent dual boot of database from different classloaders on Linux
I haven't looked at this yet, just wanted to say that when I proposed a single system property (vs. one system prop per database), there was opposition in the community. Some things to think about: o can the same database ever have 2 names - ie. if the location is /x/y/wombat and one person accesses as system=/x and db=y/wombat and another system= /x/y and db=wombat. o what about when a derby instance fails, like a null pointer or some othe bug. Will the system prop be left around? o how do you handle synchronization of 2 connects at basically the same time? V.Narayanan (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-700?page=all ] V.Narayanan updated DERBY-700: -- Attachment: DERBY-700.diff DERBY-700.stat Hi, We could solve this problem by setting a System property before booting a database and checking for the property during subsequent boots. When the database is shutdown we set the property to false. For example when we boot a database named mydb then we set the property derby.dblock.mydb = true. Now during subsequent boots we could check for this system variable and if it is set to true throw an exception. During the shutdown of the database we set this variable to false. I tried an attempt along this line in the attached patch. I HAVE NOT run the patch with security manager enabled. The sample repro attached with this issue passes with this fix. Pls note that the patch is not for a commit but is just to represent what I have in mind as a solution, in the form of code. thanx Narayanan Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: http://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Assigned To: V.Narayanan Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-700.diff, DERBY-700.stat, DualBootRepro.java, DualBootRepro2.zip Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb.
[jira] Commented: (DERBY-952) DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin
[ http://issues.apache.org/jira/browse/DERBY-952?page=comments#action_12424944 ] Rajesh Kartha commented on DERBY-952: - The test is passing under both DerbyNetClient and JCC on Windows XP (command prompt) using the 10.2.0.5 alpha - (426734) and jdk 1.5.0_07. No patch was applied Hence was wondering if the test is still failing for others and if the patch is needed. DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin -- Key: DERBY-952 URL: http://issues.apache.org/jira/browse/DERBY-952 Project: Derby Issue Type: Test Components: Regression Test Failure Affects Versions: 10.2.0.0 Environment: OS: Microsoft Windows XP Professional - 5.1.2600 Service Pack 2 Build 2600, CYGWIN_NT-5.1 1.5.18(0.132/4/2) 2005-07-02 20:30 Cygwin JVM: Sun Microsystems Inc. 1.5.0_05 Reporter: Ole Solberg Attachments: derby-952-idea.diff, DERBY-952.diff * Diff file derbyall/derbynetmats/DerbyNet/derbynetmats/NSinSameJVM.diff *** Start: NSinSameJVM jdk1.5.0_05 DerbyNet derbynetmats:derbynetmats 2006-02-05 02:01:20 *** 3 del main-NSinSameJVM: NetworkServer started 4 del main-NSinSameJVM: Connected to database NSinSameJVMTestDB;create=true 5 del getting ready to shutdown 6 del Shutdown successful. 6 add FAIL Network Server did not start Test Failed. *** End: NSinSameJVM jdk1.5.0_05 DerbyNet derbynetmats:derbynetmats 2006-02-05 02:02:10 *** * http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.1_i686-unknown/373335-derbynetmats_diff.txt -- 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-1622) Add documentation for encrypted database using encryptionKey
Add documentation for encrypted database using encryptionKey Key: DERBY-1622 URL: http://issues.apache.org/jira/browse/DERBY-1622 Project: Derby Issue Type: Task Components: Documentation Affects Versions: 10.2.0.0 Reporter: Sunitha Kambhampati Priority: Minor Fix For: 10.2.0.0 1) In Reference Manual:Section: Setting attributes for the database connection url Add the following attribute: encryptionKey=key Function Specifies the key to use for encrypting a new database or booting an existing encrypted database. The application provides the encryption key. Combining with other attributes When creating a new database, must be combined with create=true and dataEncryption=true. When booting an existing encrypted database, the encryptionAlgorithm is also required to be specified if the algorithm used when creating the database was not the default algorithm. The default encryption algorithm used by Derby is DES/CBC/NoPadding. -- create a new, encrypted database jdbc:derby:newDB;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768 -- boot an encrypted database jdbc:derby:encryptedDB;encryptionKey=6162636465666768 2) Developers Guide: http://db.apache.org/derby/docs/dev/devguide/tdevdvlp40140.html This should say , Booting an encrypted database. This section should also mention the encryptionKey attribute. http://db.apache.org/derby/docs/dev/devguide/cdevcsecure60146.html This section should also mention the encryptionKey attribute. Something like change this line from Once you have created an encrypted database, you must supply the boot password to reboot it. to If you have created an encrypted database using the bootPassword, then you must supply the boot password to reboot it. If you have created an encrypted database using the encryptionKey, then you must supply the encryptionKey to reboot it The example should also include the example to boot using the encryptionKey. For example, to access an encrypted database called encryptedDB, created with the encryptionKey c566bab9ee8b62a5ddb4d9229224c678 and with encryptionAlgorithm=AES/CBC/NoPadding, you would use the following connection URL: jdbc:derby:encryptedDB;encryptionAlgorithm=AES/CBC/NoPadding;encryptionKey=c566bab9ee8b62a5ddb4d9229224c678 -- 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-1623) Consider ANSI TRIM implementation
Consider ANSI TRIM implementation - Key: DERBY-1623 URL: http://issues.apache.org/jira/browse/DERBY-1623 Project: Derby Issue Type: Improvement Components: SQL Reporter: Emmanuel Bernard JPA is requiring databases to support this ANSI feature esp the ability to chose the trimmed character TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str) -- 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-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12424948 ] Daniel John Debrunner commented on DERBY-700: - Using system properties will require that every user running with the security manager grant a new permission in their policy file to allow setting these system properties. I thought an earlier discussion on the list had recommended not to use system properties this way. One issue with system properties is that how do atomically set and get the property, I think that is needed to perform locking? In your current patch, there is a window between where you get and set the property where another thread in a anoter class loader could come in and lock the database, resulting in two active derby instances connecting to the same database. I also don't understand why on getting the system property you are catching NullPointerException and IllegalArgumentException, how would these be thrown by System.getProperty()? Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: http://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Assigned To: V.Narayanan Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-700.diff, DERBY-700.stat, DualBootRepro.java, DualBootRepro2.zip Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- 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-1584) store/encryptionKey_jar.sql and lang/dcl.sql fails on Cygwin
[ http://issues.apache.org/jira/browse/DERBY-1584?page=comments#action_12424949 ] Andrew McIntyre commented on DERBY-1584: I also tried both of these tests and could get neither of them to fail in my Cygwin environment with several different JDKs. uname -a shows a Cygwin version of 1.5.18(0.132/4/2). store/encryptionKey_jar.sql and lang/dcl.sql fails on Cygwin Key: DERBY-1584 URL: http://issues.apache.org/jira/browse/DERBY-1584 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.2.0.0 Environment: Cygwin, Sun JDK 1.5 Reporter: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: 424402.zip, sane.zip http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/424402-derbyall_diff.txt * Diff file derbyall/encryptionAll/encryptionAll/encryptionKey_jar.diff *** Start: encryptionKey_jar jdk1.5.0_04 encryptionAll:encryptionAll 2006-07-22 01:35:47 *** 39,50d38 ij(DB1) select * from t1 order by a; A --- 1 2 3 4 5 ij(DB1) connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij(DB1) -- NEGATIVE CASE: Test with wrong encryption key. This should fail. connect 'jdbc:derby:jar:(ina.jar)db1;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB1; 52 del ERROR XBCXK: The given encryption key does not match the encryption key used when creating the database. Please ensure that you are using the correct encryption key and try again. 53 del ij(DB1) disconnect; 53a40,50 ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij select * from t1 order by a; IJ ERROR: Unable to establish connection ij connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij -- NEGATIVE CASE: Test with wrong encryption key. This should fail. connect 'jdbc:derby:jar:(ina.jar)db1;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB1; ERROR XJ040: Failed to start database 'jar:(ina.jar)db1', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij disconnect; IJ ERROR: Unable to establish connection 58 del ij(DB1) connect 'jdbc:derby:;shutdown=true'; 58a55,57 ERROR XJ040: Failed to start database 'jar:(ina.jar)db1', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.JarStorageFactory registered for identifier jar. ij connect 'jdbc:derby:;shutdown=true'; 60 del ij(DB1) -- connect to database in jar file using classpath subprotocol. 60a59 ij -- connect to database in jar file using classpath subprotocol. 64 del ij(DB1) -- create a class loader for this current thread 64a63 ij -- create a class loader for this current thread 76,87d74 ij(DB2CL) select * from t1 order by a; A --- 1 2 3 4 5 ij(DB2CL) connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij(DB2CL) -- try with wrong encryption key, this should fail. connect 'jdbc:derby:classpath:db2;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB2CL; 89 del ERROR XBCXK: The given encryption key does not match the encryption key used when creating the database. Please ensure that you are using the correct encryption key and try again. 90 del ij(DB2CL) exit; 90 add ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.CPStorageFactory registered for identifier classpath. ij select * from t1 order by a; IJ ERROR: Unable to establish connection ij connect 'jdbc:derby:;shutdown=true'; ERROR XJ015: Derby system shutdown. ij -- try with wrong encryption key, this should fail. connect 'jdbc:derby:classpath:db2;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666760' AS DB2CL; ERROR XJ040: Failed to start database 'classpath:db2', see the next exception for details. ERROR XBM0W: An exception was thrown while creating an instance of class class org.apache.derby.impl.io.CPStorageFactory registered for identifier classpath. ij exit; Test Failed. *** End: encryptionKey_jar jdk1.5.0_04 encryptionAll:encryptionAll 2006-07-22 01:36:14 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12424951 ] Daniel John Debrunner commented on DERBY-700: - LUCENE-305 and LUCENE-635 may be worth looking at, lucene is re-factoring their locking (similar requirements to Derby) and maybe they have a solution for the intra-jvm lock. Otherwise has anyone done a google search on the issue? Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: http://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Assigned To: V.Narayanan Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-700.diff, DERBY-700.stat, DualBootRepro.java, DualBootRepro2.zip Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- 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-1616) Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException
[ http://issues.apache.org/jira/browse/DERBY-1616?page=comments#action_12424956 ] David Van Couvering commented on DERBY-1616: Finally tracked down the source of this problem. I was very confused because the output files were showing SQL Exception while the code definitely sh owed it should be saying java.sql.SQLException. Then I discovered that the .tmp files had the right output, whereas the .out files did not. It turns out that for JDK 6, because there are so many different *types* of exceptions, in Sed.java we have replaced the specific exception class name with SQL Exception: . I suspect this was to avoid having to have a different set of output files for JDK 6. Someone was going to get around to telling me that, right? :) Re-running derbyall, thanks for your patience. Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException - Key: DERBY-1616 URL: http://issues.apache.org/jira/browse/DERBY-1616 Project: Derby Issue Type: Bug Affects Versions: 10.2.0.0 Environment: jdk16 /windows. Reporter: Sunitha Kambhampati Fix For: 10.2.0.0 Attachments: derbyall_report.txt jdk16 derbyall derbyall: 19 failures derbyall/derbyall.fail:lang/compressTable.sql derbyall/derbyall.fail:lang/nestedCommit.sql derbyall/derbyall.fail:lang/outparams.java derbyall/derbyall.fail:lang/procedure.java derbyall/derbyall.fail:lang/procedureInTrigger.sql derbyall/derbyall.fail:tools/importExportThruIJ.sql derbyall/derbyall.fail:tools/ieptests.sql derbyall/derbyall.fail:tools/iepnegativetests.sql derbyall/derbyall.fail:jdbcapi/statementJdbc20.java derbyall/derbyall.fail:jdbcapi/statementJdbc30.java derbyall/derbyall.fail:jdbcapi/parameterMapping.java derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/ClosedObjectTest.junit derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/UnsupportedVetter.junit derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/VerifySignatures.junit derbyall/encryptionAll/encryption.fail:stress/stress.multi derbyall/encryptionAll/storemats.fail:store/streamingColumn.java derbyall/storeall/storeall.fail:store/TransactionTable.sql derbyall/storeall/storemats.fail:store/streamingColumn.java -- 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-1624) use of direct column name rather than alias make aggregation fail (Hibernate depends on that)
use of direct column name rather than alias make aggregation fail (Hibernate depends on that) - Key: DERBY-1624 URL: http://issues.apache.org/jira/browse/DERBY-1624 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.1.3.1, 10.1.1.0 Reporter: Emmanuel Bernard Error: org.apache.derby.client.am.SqlException: Column 'MODEL0_.COL_0_0_' 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 HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'MODEL0_.COL_0_0_' is not a column in the target table., SQL State: 42X04, Error Code: -1 for select model0_.balance as col_0_0_, count(*) as col_1_0_ from account model0_ group by model0_.balance having count(*) 1 -- 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-1624) use of direct column name rather than alias make aggregation fail (Hibernate depends on that)
[ http://issues.apache.org/jira/browse/DERBY-1624?page=comments#action_12424957 ] Emmanuel Bernard commented on DERBY-1624: - Somehow related to DERBY-127 use of direct column name rather than alias make aggregation fail (Hibernate depends on that) - Key: DERBY-1624 URL: http://issues.apache.org/jira/browse/DERBY-1624 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.1.1.0, 10.1.3.1 Reporter: Emmanuel Bernard Error: org.apache.derby.client.am.SqlException: Column 'MODEL0_.COL_0_0_' 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 HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'MODEL0_.COL_0_0_' is not a column in the target table., SQL State: 42X04, Error Code: -1 for select model0_.balance as col_0_0_, count(*) as col_1_0_ from account model0_ group by model0_.balance having count(*) 1 -- 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-1624) use of direct column name rather than alias make aggregation fail (Hibernate depends on that)
[ http://issues.apache.org/jira/browse/DERBY-1624?page=comments#action_12424959 ] Emmanuel Bernard commented on DERBY-1624: - All but Derby DB works fine with it original issue from the hibernate dev list. I am working on enhancing Derby support a little bit, but have run into an issue with their syntax that I am unable to figure out. I was hoping someone on this list was familiar enough with Derby to point me in the right direction. Specifically, I am trying to properly deal with the manner in which Derby (and also DB2 largely) expects columns to be referenced in certain clauses. For example, because Hibernate always aliases columns in the select clause, derby requires that those aliases be used in certain later clauses. The query I am trying to work through right now is as follows: select model0_.name as col_0_0_, count(*) as col_1_0_ from Model model0_ group by model0_.name having count(*) 1 However, I get errors from Derby when passing this to the DB: ERROR 42X04: Column 'MODEL0_.COL_0_0_' 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 HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'MODEL0_.COL_0_0_' is not a column in the target table. If the having clause is removed, the query parses fine; I have tried various incantations regarding how to define the having clause without avail. This query seems taken almost verbatim from their reference docs, yet I cannot get this to work... http://db.apache.org/derby/docs/10.1/ref/rrefselectexpression.html Any thoughts? use of direct column name rather than alias make aggregation fail (Hibernate depends on that) - Key: DERBY-1624 URL: http://issues.apache.org/jira/browse/DERBY-1624 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.1.1.0, 10.1.3.1 Reporter: Emmanuel Bernard Error: org.apache.derby.client.am.SqlException: Column 'MODEL0_.COL_0_0_' 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 HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'MODEL0_.COL_0_0_' is not a column in the target table., SQL State: 42X04, Error Code: -1 for select model0_.balance as col_0_0_, count(*) as col_1_0_ from account model0_ group by model0_.balance having count(*) 1 -- 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-1456) Network Server agentError calls log only to console and are hard to diagnose
[ http://issues.apache.org/jira/browse/DERBY-1456?page=comments#action_12424960 ] Kathey Marsden commented on DERBY-1456: --- Sunitha, I have not had time to look at this patch, but wonder: will the errors get logged to derby.log? Network Server agentError calls log only to console and are hard to diagnose Key: DERBY-1456 URL: http://issues.apache.org/jira/browse/DERBY-1456 Project: Derby Issue Type: Sub-task Components: Network Server Affects Versions: 10.2.0.0 Reporter: Bryan Pendleton Assigned To: Sunitha Kambhampati Priority: Minor Attachments: 1456_notes.txt, derby1456.diff.txt, derby1456.stat.txt The Network Server code uses an assertion-check utility routine called agentError() under certain circumstances. When these agentError() calls arise, for example as in DERBY-1454, there is no server side logging of the error except to the console. The user application that hit DERBY-1454 had not been capturing console output and there was no clue in the derby.log, this made the problem hard to track down when they suddenly hit this boundary deep within their stress tests. See also DERBY-743 for another issue with Network Server's agentError routine. -- 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-1621) Trigger action statement is not recompile when there is a change that would affect it.
[ http://issues.apache.org/jira/browse/DERBY-1621?page=all ] Yip Ng reassigned DERBY-1621: - Assignee: Yip Ng Trigger action statement is not recompile when there is a change that would affect it. -- Key: DERBY-1621 URL: http://issues.apache.org/jira/browse/DERBY-1621 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Yip Ng Priority: Critical Fix For: 10.2.0.0 A trigger action statement, such as an INSERT statement is not recompiled when there is some DDL change on the underlying table, such as a CREATE INDEX. In the example below a unique index is added to the table (t2) inserted into by the trigger's action statement. When the tirgger fires it does not raise any error (should raise a unique constraint violated error) and does not insert the value into the index. A select from t2 does not show the additional rows in t2 as it is performing an index scan, once the index is dropped the rows appear to the select. ij version 10.2 ij connect 'jdbc:derby:cs;create=true'; ij create table t (i int); 0 rows inserted/updated/deleted ij create table t2 (i int); 0 rows inserted/updated/deleted ij create trigger tt after insert on t for each statement mode db2sql insert into t2 values 1; 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij create unique index tu on t2(i); 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij drop index tu; 0 rows inserted/updated/deleted ij select * from t2; I --- 1 1 1 3 rows selected -- 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
Checking for required classes from within Derby?
As part of my work for DERBY-688 I've made some slight changes to the XML
operators that were added in DERBY-334 and I've also added a new operator, XMLQUERY.
These operators depend on the presence of classes that are technically
external to Derby. Or more specifically, they expect that the user's
classpath will include 1) an implementation of JAXP (such as Xerces or Crimson)
and 2) Apache Xalan.
In preparation for the 10.2 exposure of the XML datatype and corresponding
operators I want to add checks in the Derby code to see if the required classes
exist and to throw a more user-friendly error if they don't (instead of some
ClassNotFoundException (or worse) in the middle of processing, which isn't very
intuitive). I currently have code working that does this by calling
Class.forName(...) and passing in the name of one of the required classes, and
then catching the resultant exception (if there is one) and converting it to
something more meaningful.
Ex:
try {
/* If the w3c Document class exists, then we
* assume a JAXP implementation is present in
* the classpath.
*
* Note: The JAXP API and implementation are
* provided as part the JVM if it is JDBC 3.0 or
* greater.
*/
Class.forName(org.w3c.dom.Document);
try {
/* If the XPath class exists, then we assume that our XML
* query processor (in this case, Xalan), is present in the
* classpath.
*/
Class.forName(org.apache.xpath.XPath);
} catch (java.lang.ClassNotFoundException e) {
// couldn't find query processor (Xalan).
user-friendly error processing
}
} catch (java.lang.ClassNotFoundException e) {
// couldn't find JAXP parser.
user-friendly error processing
}
While this works, I can't help but wonder if Derby has some sort of existing
mechanism/utilities to check for the existence of required classes in a cleaner
(and perhaps more correct?) way.
Does anyone know if such a utility/mechanism exists, and if so, can I get some
pointers to code/documentation? I admit I haven't done much searching of the
code yet; I figured I'd start with the list and maybe save some time...
Thanks much,
Army
[jira] Commented: (DERBY-1456) Network Server agentError calls log only to console and are hard to diagnose
[ http://issues.apache.org/jira/browse/DERBY-1456?page=comments#action_12424966 ] Sunitha Kambhampati commented on DERBY-1456: Yes. The errors will get logged to derby.log. Network Server agentError calls log only to console and are hard to diagnose Key: DERBY-1456 URL: http://issues.apache.org/jira/browse/DERBY-1456 Project: Derby Issue Type: Sub-task Components: Network Server Affects Versions: 10.2.0.0 Reporter: Bryan Pendleton Assigned To: Sunitha Kambhampati Priority: Minor Attachments: 1456_notes.txt, derby1456.diff.txt, derby1456.stat.txt The Network Server code uses an assertion-check utility routine called agentError() under certain circumstances. When these agentError() calls arise, for example as in DERBY-1454, there is no server side logging of the error except to the console. The user application that hit DERBY-1454 had not been capturing console output and there was no clue in the derby.log, this made the problem hard to track down when they suddenly hit this boundary deep within their stress tests. See also DERBY-743 for another issue with Network Server's agentError routine. -- 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-1620) SQL CASE statement returns ERROR 42X89 when including NULL as a return value
[ http://issues.apache.org/jira/browse/DERBY-1620?page=comments#action_12424967 ] John Peterson commented on DERBY-1620: -- It has been brought to my attention that the SQL2003_Standard_Case_Expression.doc is a violation of the ISO copyright, I suggest it be removed as soon as possible. Instead, please refer to http://en.wikipedia.org/wiki/SQL:2003 for a link to a .zip file (sql_2003_standard.zip), and open the 5WD-02-Foundation-2003-09.pdf within. Turn to page 197 (221 of 1332) (Chapter 6.11) to view the Case Expression standard. SQL CASE statement returns ERROR 42X89 when including NULL as a return value Key: DERBY-1620 URL: http://issues.apache.org/jira/browse/DERBY-1620 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1 Environment: Windows XP Reporter: John Peterson Attachments: Derby_Community_Discussion.doc, SQL2003_Standard_Case_Expression.doc, sysinfo_and_example.txt This bug appears to be related to the DERBY-7 bug (NULLIF() function). When NULL is used during a CASE statement, Derby requires the NULL to be CAST to the appropriate type. This does not appear to meet the SQL 2003 Standard for the Case Expression (see attached Word document). See the attached Word document to view the Derby Community Discussion about this issue. See the attached .TXT to view the SYSINFO and to see an example of the steps to reproduce using IJ. Steps to Reproduce: ijvalues case when 1=2 then 3 else NULL end; ERROR 42X89: Types 'INTEGER' and 'CHAR' are not type compatible. Neither type is assignable to the other type. Current Workaround: ijvalues case when 1=2 then 3 else cast(NULL as INT) 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-1621) Trigger action statement is not recompile when there is a change that would affect it.
[ http://issues.apache.org/jira/browse/DERBY-1621?page=comments#action_12424968 ] Daniel John Debrunner commented on DERBY-1621: -- Thanks for looking at this Yip - note that Derby has an existing dependency system already, thus it should be possible to fix this using the existing scheme rather than inventing anything new. E.g. in my example script the select * from t2 does receive to invalidations for the create and drop indexes which allow it to be recompiled to go against the base table or index. Trigger action statement is not recompile when there is a change that would affect it. -- Key: DERBY-1621 URL: http://issues.apache.org/jira/browse/DERBY-1621 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Yip Ng Priority: Critical Fix For: 10.2.0.0 A trigger action statement, such as an INSERT statement is not recompiled when there is some DDL change on the underlying table, such as a CREATE INDEX. In the example below a unique index is added to the table (t2) inserted into by the trigger's action statement. When the tirgger fires it does not raise any error (should raise a unique constraint violated error) and does not insert the value into the index. A select from t2 does not show the additional rows in t2 as it is performing an index scan, once the index is dropped the rows appear to the select. ij version 10.2 ij connect 'jdbc:derby:cs;create=true'; ij create table t (i int); 0 rows inserted/updated/deleted ij create table t2 (i int); 0 rows inserted/updated/deleted ij create trigger tt after insert on t for each statement mode db2sql insert into t2 values 1; 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij create unique index tu on t2(i); 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij drop index tu; 0 rows inserted/updated/deleted ij select * from t2; I --- 1 1 1 3 rows selected -- 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-1620) SQL CASE statement returns ERROR 42X89 when including NULL as a return value
[ http://issues.apache.org/jira/browse/DERBY-1620?page=all ] Andrew McIntyre updated DERBY-1620: --- Attachment: (was: SQL2003_Standard_Case_Expression.doc) SQL CASE statement returns ERROR 42X89 when including NULL as a return value Key: DERBY-1620 URL: http://issues.apache.org/jira/browse/DERBY-1620 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1 Environment: Windows XP Reporter: John Peterson Attachments: Derby_Community_Discussion.doc, sysinfo_and_example.txt This bug appears to be related to the DERBY-7 bug (NULLIF() function). When NULL is used during a CASE statement, Derby requires the NULL to be CAST to the appropriate type. This does not appear to meet the SQL 2003 Standard for the Case Expression (see attached Word document). See the attached Word document to view the Derby Community Discussion about this issue. See the attached .TXT to view the SYSINFO and to see an example of the steps to reproduce using IJ. Steps to Reproduce: ijvalues case when 1=2 then 3 else NULL end; ERROR 42X89: Types 'INTEGER' and 'CHAR' are not type compatible. Neither type is assignable to the other type. Current Workaround: ijvalues case when 1=2 then 3 else cast(NULL as INT) 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-1620) SQL CASE statement returns ERROR 42X89 when including NULL as a return value
[ http://issues.apache.org/jira/browse/DERBY-1620?page=comments#action_12424969 ] Andrew McIntyre commented on DERBY-1620: Removed SQL2003_Standard_Case_Expression.doc attachment at attcher's request. SQL CASE statement returns ERROR 42X89 when including NULL as a return value Key: DERBY-1620 URL: http://issues.apache.org/jira/browse/DERBY-1620 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1 Environment: Windows XP Reporter: John Peterson Attachments: Derby_Community_Discussion.doc, sysinfo_and_example.txt This bug appears to be related to the DERBY-7 bug (NULLIF() function). When NULL is used during a CASE statement, Derby requires the NULL to be CAST to the appropriate type. This does not appear to meet the SQL 2003 Standard for the Case Expression (see attached Word document). See the attached Word document to view the Derby Community Discussion about this issue. See the attached .TXT to view the SYSINFO and to see an example of the steps to reproduce using IJ. Steps to Reproduce: ijvalues case when 1=2 then 3 else NULL end; ERROR 42X89: Types 'INTEGER' and 'CHAR' are not type compatible. Neither type is assignable to the other type. Current Workaround: ijvalues case when 1=2 then 3 else cast(NULL as INT) 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
Re: [jira] Commented: (DERBY-1616) Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException
On 8/1/06, David Van Couvering (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1616?page=comments#action_12424956 ] David Van Couvering commented on DERBY-1616: Finally tracked down the source of this problem. I was very confused because the output files were showing SQL Exception while the code definitely sh owed it should be saying java.sql.SQLException. [snip] Someone was going to get around to telling me that, right? :) Actually, I did send a message wondering about this, but it was a reply to one of the failure reports, you must've missed it. http://www.nabble.com/Regression-Test-Failure%21---Derby-426908---Sun-DBTG-tf2026368.html#a5572398 :-) Re-running derbyall, thanks for your patience. Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException
Re: [jira] Assigned: (DERBY-1621) Trigger action statement is not recompile when there is a change that would affect it.
Yip Ng (JIRA) wrote: Trigger action statement is not recompile when there is a change that would affect it. -- Is it possible DERBY-1603 is at all related to this bug, where the change is changing versions? Just a long shot but hoping
Re: Checking for required classes from within Derby?
Army wrote: As part of my work for DERBY-688 I've made some slight changes to the XML operators that were added in DERBY-334 and I've also added a new operator, XMLQUERY. [snip] While this works, I can't help but wonder if Derby has some sort of existing mechanism/utilities to check for the existence of required classes in a cleaner (and perhaps more correct?) way. Does anyone know if such a utility/mechanism exists, and if so, can I get some pointers to code/documentation? I admit I haven't done much searching of the code yet; I figured I'd start with the list and maybe save some time... Derby's loading of modules from modules.properties has a mechanism where a module is not loaded if its declared list of classes are not loadable. E.g. derby.module.jdbcJ2=org.apache.derby.jdbc.Driver20 derby.env.jdk.jdbcJ2=2 derby.env.classes.jdbcJ2=java.sql.Driver Only load the org.apache.derby.jdbc.Driver20 module if java.sql.Driver is loadable. So maybe you could look at that code to see if it helps. Otherwise the utility class org.apache.derby.iapi.services.loader.ClassInspector has some methods, you could add a new utility method there. Dan. PS. Tthis code comment is technically incorrect, JDBC 3 has nothing to do with JAXP, JAXP api is driven by the JDK level not the JDBC level. * Note: The JAXP API and implementation are * provided as part the JVM if it is JDBC 3.0 or * greater.
Re: [jira] Updated: (DERBY-1547) Add svn version number to DatabaseMetaData getDatabaseProductVersion and getDriverVersion() to improve supportability
Does anyone think this is a bad idea? Seems simple and a good idea to me but it is changing an exported format. Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1547?page=all ] Kathey Marsden updated DERBY-1547: -- Urgency: Normal (was: Low) Changing this to Normal Urgency. It would be a huge supportability improvement, and can only happen in a feature release, so it would be good to get in now. Add svn version number to DatabaseMetaData getDatabaseProductVersion and getDriverVersion() to improve supportability --- Key: DERBY-1547 URL: http://issues.apache.org/jira/browse/DERBY-1547 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.1.3.2 Reporter: Kathey Marsden Priority: Minor Fix For: 10.2.0.0 getDatabaseProductVersion and getDriverVersion() report only the four digit Derby version number and not the svn build number. It would be useful to return the full version including the build number as sysinfo does: e.g. 10.1.2.4 - (392472), That way it will be clear from application logs that collect this information exactly what revision level they are running if they are using rolled up fixes on the maintenance branch between releases. There may be risk in doing this however if applications are parsing the version information, but hopefully they will use getDatabaseMajorVersion() , getDatbaseMinorVersion, getDriverMajorVersion, and getDriverMinorVersion for such proccessing.
[jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12424974 ] Satheesh Bandaram commented on DERBY-1057: -- All the answers provided by Mamta earlier are correct. Grant/Revoke statements can only operate on one object at a time.. though it may be possible to grant/revoke several actions to several different users in one statement. So, all the following are possible: GRANT SELECT, UPDATE, REFERENCES ON T TO SAM, RAM, PAM; REVOKE SELECT, UPDATE, REFERENCES ON T FROM SAM, RAM, PAM; GRANT EXECUTE ON FUNCTION F_ABS123(INT) TO SAM, PAM; REVOKE EXECUTE ON FUNCTION F_ABS123 FROM SAM, PAM RESTRICT; But NOT the following: GRANT SELECT ON T, T1 TO SAM; Granting Select on two different tables in statement Similarly granting EXECUTE on multiple functions (or procedures) in statement is NOT allowed, same behavior with REVOKE as well. Regarding routine signatures, I can update the spec to add some grammar info. Laura, let me know if you need any further info for documentation. BIG thanks for attempting to document this feature. documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.0 Reporter: Eric Radzinski Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide_html.zip, derby1057_ref.diff, derby1057_ref_html.zip, devguide_html2.zip, ref_html2.zip -- 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: Checking for required classes from within Derby?
Daniel John Debrunner wrote: Derby's loading of modules from modules.properties has a mechanism where a module is not loaded if its declared list of classes are not loadable. snip Otherwise the utility class org.apache.derby.iapi.services.loader.ClassInspector has some methods, you could add a new utility method there. Thanks for the suggestions (and quick reply), Dan. I'll start with these and see which approach seems most appropriate. PS. Tthis code comment is technically incorrect, JDBC 3 has nothing to do with JAXP, JAXP api is driven by the JDK level not the JDBC level. Corrected. Thanks again, Army
Re: [jira] Assigned: (DERBY-1621) Trigger action statement is not recompile when there is a change that would affect it.
Hmm.. not sure, but I'll dig into it.On 8/1/06, Kathey Marsden [EMAIL PROTECTED] wrote: Yip Ng (JIRA) wrote:Trigger action statement is not recompile when there is a change that would affect it. --Is it possible DERBY-1603 is at all related to this bug, where thechangeis changing versions? Just a long shot but hoping
Re: svn commit: r427293 - in /db/derby/code/trunk/java/tools/org/apache/derby/impl/tools/ij: Main.java mtTestCase.java utilMain.java utilMain14.java
On 7/31/06, Andrew McIntyre [EMAIL PROTECTED] wrote: On 7/31/06, Army [EMAIL PROTECTED] wrote: [javac] Compiling 2 source files to C:\p4clients\main_codeline\classes [javac] C:\p4clients\main_codeline\opensource\java\testing\org\apache\derbyTesting\functionTests\tests\lang\wisconsin.java:70: utilMain(int,org.apache.derby.iapi.tools.i18n.LocalizedOutput,java.util.Hashtable) is not public in org.apache.derby.impl.tools.ij.utilMain; cannot be accessed from outside package [javac] utilInstance = new utilMain(1, out, (Hashtable)null); [javac]^ [javac] 1 error [javac] Compile failed; see the compiler error output for details. Interestingly, the wisconsin test is usign this internal class to set ij's input and output streams. Since that's exactly what the public ij.runScript() is for, the test should probably be rewritten to use the new public api. I also noticed (somewhat by chance) that if I try to run ij using Sun jdk131 with the latest codeline, I see the following: Exception in thread main java.lang.UnsupportedClassVersionError: org/apache/derby/impl/tools/ij/Main14 (Unsupported major.minor version 48.0) I'll look into this. andrew So, Andrew, does this also mean you are looking into the wisconsin test failure? The test currently builds but fails - with jdk142 and others, I think. Looks like it just can't make any connections, haven't looked further into it. This I saw first when svn update-ing up to 427354. Or, Dan, that was a checkin by you, are you maybe looking at it? Myrna
[jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12424980 ] Laura Stewart commented on DERBY-1330: -- In the spec AuthorizationModelForDerbySQLStandardAuthorizationV2.html, I am not sure that I understand the sentences in this paragraph : Authorization checking is of little value unless Derby authentication is turned on. By default, Derby's authentication is OFF and can be turned ON by setting derby.connection.requireAuthentication to TRUE. Attempts to set security mode to Derby SQL Standard Authorization mode without first requiring authentication will raise a warning. Questions: 1. The text here refers to derby.connection.requireAuthentication, how is that different from derby.database.defaultConnectionMode and derby.database.sqlAuthorization ? 2. The last sentence in the paragraph from the spec is confusing. It is unclear what requiring authentication means. Is that user authentication, Derby authentication? What is clear is that authentication must be set before the security mode is set. The sentence implies that Derby SQL Standard Authorization is a mode that can be set for security. How is the security mode set? I'd appreciate any clarification that you can provide. Provide runtime privilege checking for grant/revoke functionality - Key: DERBY-1330 URL: http://issues.apache.org/jira/browse/DERBY-1330 Project: Derby Issue Type: Sub-task Components: SQL Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Mamta A. Satoor Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, AuthorizationModelForDerbySQLStandardAuthorizationV2.html, DERBY1330javaDocWarningsDiffV9.txt, DERBY1330javaDocWarningsStatV9.txt, Derby1330MinorCleanupV7diff.txt, Derby1330MinorCleanupV7stat.txt, Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330setUUIDinDataDictionaryV10diff.txt, Derby1330setUUIDinDataDictionaryV10stat.txt, Derby1330setUUIDinDataDictionaryV8diff.txt, Derby1330setUUIDinDataDictionaryV8stat.txt, Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330uuidIndexForPermsSystemTablesV4stat.txt, Derby1330uuidIndexForPermsSystemTablesV5diff.txt, Derby1330uuidIndexForPermsSystemTablesV5stat.txt, Derby1330uuidIndexForPermsSystemTablesV6diff.txt, Derby1330uuidIndexForPermsSystemTablesV6stat.txt, Derby1330ViewPrivilegeCollectionV1diff.txt, Derby1330ViewPrivilegeCollectionV1stat.txt Additional work needs to be done for grant/revoke to make sure that only users with required privileges can access various database objects. In order to do that, first we need to collect the privilege requirements for various database objects and store them in SYS.SYSREQUIREDPERM. Once we have this information then when a user tries to access an object, the required SYS.SYSREQUIREDPERM privileges for the object will be checked against the user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS. The database object access will succeed only if the user has the necessary privileges. SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't have any information in it at this point and hence no runtime privilege checking is getting done at this point. -- 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-1579) Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality
[ http://issues.apache.org/jira/browse/DERBY-1579?page=comments#action_12424985 ] Deepa Remesh commented on DERBY-1579: - I went through this patch and it looks good to me. With this patch, I confirmed that SYS.SYSREQUIREDPERM table does not get created. However, the patch does not apply cleanly to the latest codeline and needs to be updated. Some of the master files have conflicts. Yip, can you please post an updated patch for this? Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality - Key: DERBY-1579 URL: http://issues.apache.org/jira/browse/DERBY-1579 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Yip Ng Priority: Minor Fix For: 10.2.0.0 Attachments: derby1579trunkdiff01.txt, derby1579trunkstat01.txt With the Grant Revoke functionality. Derby engine needs to keep track of view/constraint/trigger's dependencies on various privileges. SYS.SYSREQUIREDPERM table was added for this purpose. But these depdencies can be mantained using the existing Dependency Manager. I have done quite a bit of work using Dependency Manager for Grant Revoke and do not see a need for SYS.SYSREQUIREDPERM. Before 10.2 release, we should drop SYS.SYSREQUIREDPERM from the Derby code and update the Grant/Revoke functional spec accordingly. -- 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-1625) wisconsin test unable to establish connection
wisconsin test unable to establish connection - Key: DERBY-1625 URL: http://issues.apache.org/jira/browse/DERBY-1625 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.2.0.0 Environment: linux jdk1.4 Reporter: Rick Hillegas Fix For: 10.2.0.0 The wisconsin test fails to get a connection on linux under jkd1.4 -- 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-1626) TransactionTable.sql fails
TransactionTable.sql fails -- Key: DERBY-1626 URL: http://issues.apache.org/jira/browse/DERBY-1626 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.2.0.0 Environment: linux jdk1.4 Reporter: Rick Hillegas Fix For: 10.2.0.0 TransactionTable fails with the following diff: 226a227 NULL |SystemTransaction |IDLE|readonly|NULL Test Failed. *** End: TransactionTable jdk1.4.2_08 2006-08-01 12:47:35 *** -- 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-1579) Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality
Will do. =)On 8/1/06, Deepa Remesh (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1579?page=comments#action_12424985 ]Deepa Remesh commented on DERBY-1579: -I went through this patch and it looks good to me. With this patch, I confirmed that SYS.SYSREQUIREDPERMtable does not get created. However, the patch does not apply cleanly to the latest codeline and needs to be updated. Some of the master files have conflicts. Yip, can you please post an updated patch for this? Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality - Key: DERBY-1579 URL: http://issues.apache.org/jira/browse/DERBY-1579 Project: DerbyIssue Type: Improvement Components: SQLAffects Versions: 10.2.0.0Reporter: Mamta A. Satoor Assigned To: Yip NgPriority: Minor Fix For: 10.2.0.0 Attachments: derby1579trunkdiff01.txt, derby1579trunkstat01.txt With the Grant Revoke functionality. Derby engine needs to keep track of view/constraint/trigger's dependencies on various privileges. SYS.SYSREQUIREDPERM table was added for this purpose. But these depdencies can be mantained using the existing Dependency Manager. I have done quite a bit of work using Dependency Manager for Grant Revoke and do not see a need for SYS.SYSREQUIREDPERM. Before 10.2 release, we should drop SYS.SYSREQUIREDPERM from the Derby code and update the Grant/Revoke functional spec accordingly.--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-1597) Scripts in frameworks direcotry needs to be revisted to set up CLASSPATH properly
[
http://issues.apache.org/jira/browse/DERBY-1597?page=comments#action_12425010 ]
Ramandeep Kaur commented on DERBY-1597:
---
Actually, after thinking about it more, I am proposing the following solution:-
Give classpath while invoking java classes as following:
%JAVA_HOME%/bin/java -cp %MYCLASSPATH% org.apache.derby.tools.ij
Where MYCLASSPATH will include derby jar files along with system classpath
appended to it.
Will submit patch.
Scripts in frameworks direcotry needs to be revisted to set up CLASSPATH
properly
-
Key: DERBY-1597
URL: http://issues.apache.org/jira/browse/DERBY-1597
Project: Derby
Issue Type: Bug
Components: Demos/Scripts
Affects Versions: 10.2.0.0
Reporter: Ramandeep Kaur
Assigned To: Andrew McIntyre
Need to revisit scripts in directory frameworks/embedded/bin and
frameworks/NetworkServer/bin for setting up CLASSPATH properly. The current
problem is as following:
If user already has a CLASSPATH set on their system, the CLASSPATH is not set
again within the script. Therefore, there are no derby classes in the
CLASSPATH which results in java command failing as it can not find the derby
class it is calling. Basically, to make the scripts work, user has to either
issue command set CLASSPATH= or have derby jar files be appended to their
system CLASSPATH before running any frameworks batch script.
In ksh scripts, there is same problem except that the user has to issue
command export CLASSPATH= or have derby jar files be appended to their
system CLASSPATH only once as whatever CLASSPATH is set up by scripts is not
visible once the script is done.
So I am proposing the following solution so that frameworks scripts work
properly without interfering with system classpath or without any setup from
user.
In batch scripts:-
--
1. Before line call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat, save the
current classpath as follows:
set SAVED_CLASSPATH=%CLASSPATH%
2. Replace the following lines:
@if !%CLASSPATH%==! call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
@if %CLASSPATH% == call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
with
call %DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
Note: I have given the above as example only. The name of script that is
getting called may be different.
3. At the end of script, reset the CLASSPATH to system CLASSPATH as follows:
set CLASSPATH=%SAVED_CLASSPATH%
In korn scripts:-
--
In ksh script, even though system classpath is only modified within the
script and is not effective once script exits, to be consistent with batch
scripts, do the following:
1. Before line . $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
save the current classpath as follows:
export SAVED_CLASSPATH=$CLASSPATH
2. Replace the following lines:
[ -z $CLASSPATH ] {
. $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
}
with
. $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
Note: I have given the above as example only. The name of script that is
getting called may be different.
3. At the end of script, reset the CLASSPATH to system CLASSPATH as follows:
export CLASSPATH=$SAVED_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
Re: [jira] Commented: (DERBY-1621) Trigger action statement is not recompile when there is a change that would affect it.
Thanks for the info, Dan. I briefly looked at the reported issue, I think I know what the problem is. When Derby binds the trigger's action node (insert stmt in this case) in CreateTriggerNode, the action node bind phase creates a dependency from the compilation context but however, the context's current dependent is not the insert statement itself but of the trigger statement. Hence, that is probably the reason why the insert statement didn't get invalidated when create/drop index is executed. On 8/1/06, Daniel John Debrunner (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1621?page=comments#action_12424968 ]Daniel John Debrunner commented on DERBY-1621: --Thanks for looking at this Yip - note that Derby has an existing dependency system already, thus it should be possible to fix this using the existing scheme rather than inventing anything new. E.g. in my example script the select * from t2 does receive to invalidations for the create and drop indexes which allow it to be recompiled to go against the base table or index. Trigger action statement is not recompile when there is a change that would affect it. -- Key: DERBY-1621 URL: http://issues.apache.org/jira/browse/DERBY-1621 Project: DerbyIssue Type: BugComponents: SQLAffects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Yip NgPriority: Critical Fix For: 10.2.0.0 A trigger action statement, such as an INSERT statement is not recompiled when there is some DDL change on the underlying table, such as a CREATE INDEX. In the example below a unique index is added to the table (t2) inserted into by the trigger's action statement. When the tirgger fires it does not raise any error (should raise a unique constraint violated error) and does not insert the value into the index. A select from t2 does not show the additional rows in t2 as it is performing an index scan, once the index is dropped the rows appear to the select. ij version 10.2 ij connect 'jdbc:derby:cs;create=true'; ij create table t (i int); 0 rows inserted/updated/deleted ij create table t2 (i int); 0 rows inserted/updated/deleted ij create trigger tt after insert on t for each statement mode db2sql insert into t2 values 1; 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij create unique index tu on t2(i); 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij drop index tu; 0 rows inserted/updated/deleted ij select * from t2; I --- 1 1 1 3 rows selected--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-1241) When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirror
[ http://issues.apache.org/jira/browse/DERBY-1241?page=all ] Myrna van Lunteren updated DERBY-1241: -- Attachment: DERBY-1241_20060801.diff I'm attaching a patch -DERBY-1241_20060801.diff - that fixes the reproducible case described in this bug, using the fix suggested by Andreas in DERBY-1598, and ran derbyall on it. As expected (because derbyall never caught this problem) I saw no unexpected failures (failed: wisconsin (DERBY-1625), TransactionTable(DERBY-1626)). When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirror.ctrl if database was not shutdown cleanly after previous access -- Key: DERBY-1241 URL: http://issues.apache.org/jira/browse/DERBY-1241 Project: Derby Issue Type: Bug Components: Store Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-1241_20060801.diff, derby_tests.policy logmirror.ctrl is getting accessed outside the privileged block when the checkpoint instant is invalid on log factory boot method and cause this failure on boot if the database was not shutdown cleanly. The reproduction (see comment) shows that can happens after database creation. This problem was reported on the derby-dev list by Olav Sandstaa , filing jira entry for it. Olav Sandstaa wrote: Rick Hillegas [EMAIL PROTECTED] wrote: java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission /export/home/tmp/derbyjdbc4/DerbyNetClient/TestConnectionMethods/wombat/log/logmirror.ctrl read): java.security.AccessControlException'. at java.security.AccessControlContext.checkPermission(AccessControlContext.java:321) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:731) at org.apache.derby.impl.store.raw.log.LogToFile.boot(LogToFile.java:2940) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(BaseDataFileFactory.java:1762) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(BaseDataFileFactory.java:1218) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:250) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:987) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:738) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:178) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1831) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1697) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1577) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541) at
[jira] Created: (DERBY-1627) Need a regression test for DERBY-1241
Need a regression test for DERBY-1241 - Key: DERBY-1627 URL: http://issues.apache.org/jira/browse/DERBY-1627 Project: Derby Issue Type: Test Affects Versions: 10.2.0.0 Reporter: Myrna van Lunteren The bug described in DERBY-1241 needs a regression test that verifies this works correctly. -- 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-1241) When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirror
[ http://issues.apache.org/jira/browse/DERBY-1241?page=all ] Myrna van Lunteren updated DERBY-1241: -- Derby Info: [Patch Available] When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirror.ctrl if database was not shutdown cleanly after previous access -- Key: DERBY-1241 URL: http://issues.apache.org/jira/browse/DERBY-1241 Project: Derby Issue Type: Bug Components: Store Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-1241_20060801.diff, derby_tests.policy logmirror.ctrl is getting accessed outside the privileged block when the checkpoint instant is invalid on log factory boot method and cause this failure on boot if the database was not shutdown cleanly. The reproduction (see comment) shows that can happens after database creation. This problem was reported on the derby-dev list by Olav Sandstaa , filing jira entry for it. Olav Sandstaa wrote: Rick Hillegas [EMAIL PROTECTED] wrote: java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission /export/home/tmp/derbyjdbc4/DerbyNetClient/TestConnectionMethods/wombat/log/logmirror.ctrl read): java.security.AccessControlException'. at java.security.AccessControlContext.checkPermission(AccessControlContext.java:321) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:731) at org.apache.derby.impl.store.raw.log.LogToFile.boot(LogToFile.java:2940) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(BaseDataFileFactory.java:1762) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(BaseDataFileFactory.java:1218) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:250) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:987) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:738) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:178) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1831) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1697) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1577) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1586) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:216) at org.apache.derby.impl.jdbc.EmbedConnection30.init(EmbedConnection30.java:72) at org.apache.derby.impl.jdbc.EmbedConnection40.init(EmbedConnection40.java:48) at
[jira] Updated: (DERBY-1579) Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality
[ http://issues.apache.org/jira/browse/DERBY-1579?page=all ] Yip Ng updated DERBY-1579: -- Attachment: derby1579trunkstat02.txt derby1579trunkdiff02.txt Resubmitting patch - derby1579trunkdiff02.txt Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality - Key: DERBY-1579 URL: http://issues.apache.org/jira/browse/DERBY-1579 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Yip Ng Priority: Minor Fix For: 10.2.0.0 Attachments: derby1579trunkdiff01.txt, derby1579trunkdiff02.txt, derby1579trunkstat01.txt, derby1579trunkstat02.txt With the Grant Revoke functionality. Derby engine needs to keep track of view/constraint/trigger's dependencies on various privileges. SYS.SYSREQUIREDPERM table was added for this purpose. But these depdencies can be mantained using the existing Dependency Manager. I have done quite a bit of work using Dependency Manager for Grant Revoke and do not see a need for SYS.SYSREQUIREDPERM. Before 10.2 release, we should drop SYS.SYSREQUIREDPERM from the Derby code and update the Grant/Revoke functional spec accordingly. -- 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-1616) Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException
Yes, it's easy for data like this to slip through with the volume of email on this list. I'm not sure how to resolve that, there's just going to be some amount of lossiness in the system... David Myrna van Lunteren wrote: On 8/1/06, David Van Couvering (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1616?page=comments#action_12424956 ] David Van Couvering commented on DERBY-1616: Finally tracked down the source of this problem. I was very confused because the output files were showing SQL Exception while the code definitely sh owed it should be saying java.sql.SQLException. [snip] Someone was going to get around to telling me that, right? :) Actually, I did send a message wondering about this, but it was a reply to one of the failure reports, you must've missed it. http://www.nabble.com/Regression-Test-Failure%21---Derby-426908---Sun-DBTG-tf2026368.html#a5572398 :-) Re-running derbyall, thanks for your patience. Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException
[jira] Updated: (DERBY-1252) Old clients with new server return wrong database metadata values for some methods
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
-
Attachment: derby1252.stat
derby1252.diff
derby1252-10.1.stat
Old clients with new server return wrong database metadata values for some
methods
--
Key: DERBY-1252
URL: http://issues.apache.org/jira/browse/DERBY-1252
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1,
10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
Reporter: Dag H. Wanvik
Assigned To: Dag H. Wanvik
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby1252-10.1.stat, derby1252.diff, derby1252.stat
With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
some metadata calls will return the wrong value for both the JCC and
the Derby clients:
deletesAreDetected(TYPE_SCROLL_INSENSITIVE) - true
updatedAreDetected(TYPE_SCROLL_INSENSITIVE) - true
ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
This happens because these values were changed for the 10.2 with
the addition of updatable scrollable insensitive result sets (DERBY-775),
combined with a weakness in the way the client and the server
cooperates to answer these metadata calls.
Presently, when the client application invokes these methods, the
results will be returned by the server without regard to the identity
of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
The values to be returned for the methods in question are based solely
on the values found in the file metadata_net.properties, which is part
of the server.
In general, some database metadata is dependent on the combination of
the capabilities in the client and the server and the returned values
should reflect this, which in general implies negotiating (down) to
values which are correct for the actual combination of client and
server.
--
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-1628) Update name of driver - IBM DB2 JDBC Universal Driver to IBM DB2 Driver for JDBC
Update name of driver - IBM DB2 JDBC Universal Driver to IBM DB2 Driver for JDBC Key: DERBY-1628 URL: http://issues.apache.org/jira/browse/DERBY-1628 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.0.0 Reporter: Laura Stewart Assigned To: Laura Stewart Priority: Minor The name of this driver is inaccurate, the name has changed. -- 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-1252) Old clients with new server return wrong database metadata values for some methods
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
-
Attachment: derby1252-10.1.diff
Old clients with new server return wrong database metadata values for some
methods
--
Key: DERBY-1252
URL: http://issues.apache.org/jira/browse/DERBY-1252
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1,
10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
Reporter: Dag H. Wanvik
Assigned To: Dag H. Wanvik
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby1252-10.1.diff, derby1252-10.1.stat,
derby1252.diff, derby1252.stat
With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
some metadata calls will return the wrong value for both the JCC and
the Derby clients:
deletesAreDetected(TYPE_SCROLL_INSENSITIVE) - true
updatedAreDetected(TYPE_SCROLL_INSENSITIVE) - true
ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
This happens because these values were changed for the 10.2 with
the addition of updatable scrollable insensitive result sets (DERBY-775),
combined with a weakness in the way the client and the server
cooperates to answer these metadata calls.
Presently, when the client application invokes these methods, the
results will be returned by the server without regard to the identity
of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
The values to be returned for the methods in question are based solely
on the values found in the file metadata_net.properties, which is part
of the server.
In general, some database metadata is dependent on the combination of
the capabilities in the client and the server and the returned values
should reflect this, which in general implies negotiating (down) to
values which are correct for the actual combination of client and
server.
--
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] Created: (DERBY-1626) TransactionTable.sql fails
Note that you have multiple failures on TransactionTable right now in JDK 1.6, because it also is involved in the SQL Exception toString() debacle... I hope to be submitting a patch later today that will fix the SQL Exception problem... David Rick Hillegas (JIRA) wrote: TransactionTable.sql fails -- Key: DERBY-1626 URL: http://issues.apache.org/jira/browse/DERBY-1626 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.2.0.0 Environment: linux jdk1.4 Reporter: Rick Hillegas Fix For: 10.2.0.0 TransactionTable fails with the following diff: 226a227 NULL |SystemTransaction |IDLE|readonly|NULL Test Failed. *** End: TransactionTable jdk1.4.2_08 2006-08-01 12:47:35 ***
[jira] Commented: (DERBY-1252) Old clients with new server return wrong database metadata values for some methods
[
http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12425042 ]
Dag H. Wanvik commented on DERBY-1252:
--
Two patches are uploaded to solve this issue.
derby1252-10.1.{diff,stat}
derby1252.{diff,stat}
The first patch to the 10.1 trunk contains extensions to
jdbcapi/metadata_test.java (plus updated masters, hope I got them
all..) which can be used to verify the regression; the old version did
not contain the calls to the methods of interest, see below. I am not
sure it is necessary to commit this patch, but it is useful when
verifying the main patch.
The main patch to 10.2. trunk implements alternative 2 outlined
earlier in this issue. BTW, alternative 1 is not workable since all
logic on the server side is generic query processing making it ugly to
differentiate between clients.
Patch details:
- metadata_net.properties has been rolled back to the 10.1 version of
the four values which gave regression:
deletesAreDetected(TYPE_SCROLL_INSENSITIVE)
updatedAreDetected(TYPE_SCROLL_INSENSITIVE)
ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE)
ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE)
Derbynet master has been updated to reflect this (existing master
reflects the regression).
- am/DatabaseMetaData.java contains logic to override these to true
when running against a = 10.2. server. I also added code, which is
presently commented out, to negotiate down (effectivly an AND for
these boolean values) once the server can start returning the
correct values. As far as I can understand, this cannot happen until
we hit the next major release, 11, due to the forward compatibility
requirements for client/server,
cf. http://wiki.apache.org/db-derby/ForwardCompatibility.
- If the present solution is committed I will file a JIRA to be fixed
for Derby 11 (not possible yet?) , to move to the new regime from
Derby 11.0.
Testing:
- Ran derbyall on 10.1 trunk with the extended 10.1 metadata test
(derby1252-10.1.diff):
derbyall/derbynetmats/derbynetmats.fail:derbynet/DerbyNetAutoStart.java
derbyall/derbyall.fail:unit/T_Diagnosticable.unit
This is unrelated.
- Ran derbyall on 10.2 trunk with the patch (derby1252.diff):
wisconsin fails for all clients, plus store/TransactionTable.sql
(same as tinderbox).
- Ran 10.1 client and extended 10.1 metadata test against current 10.2
to show regression: Ok, shows regression.
- Ran JCC client and extended 10.1 metadata test against current 10.2
to show regression: Ok, shows regression.
- Ran 10.1 client and extended 10.1 metadata test against patched 10.2
to show regression has gone away: OK.
- Ran JCC client and extended 10.1 metadata test against patched 10.2
to show regression has gone away: OK.
- Ran patched 10.2 client against 10.1 server and and extended 10.1
metadata test to see that the patched 10.2 client downgrades
correctly: OK
The patch is ready for review.
Old clients with new server return wrong database metadata values for some
methods
--
Key: DERBY-1252
URL: http://issues.apache.org/jira/browse/DERBY-1252
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1,
10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
Reporter: Dag H. Wanvik
Assigned To: Dag H. Wanvik
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby1252-10.1.diff, derby1252-10.1.stat,
derby1252.diff, derby1252.stat
With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
some metadata calls will return the wrong value for both the JCC and
the Derby clients:
deletesAreDetected(TYPE_SCROLL_INSENSITIVE) - true
updatedAreDetected(TYPE_SCROLL_INSENSITIVE) - true
ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
This happens because these values were changed for the 10.2 with
the addition of updatable scrollable insensitive result sets (DERBY-775),
combined with a weakness in the way the client and the server
cooperates to answer these metadata calls.
Presently, when the client application invokes these methods, the
results will be returned by the server without regard to the identity
of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
The values to be returned for the methods in question are based solely
on the values found in the file metadata_net.properties, which is part
of the server.
In general, some database metadata is dependent on the combination of
the capabilities in the client and the server and the returned values
should reflect this, which in general implies negotiating (down) to
values which are correct for the actual
[jira] Updated: (DERBY-1252) Old clients with new server return wrong database metadata values for some methods
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
-
Attachment: derby1252.diff
whitespace fix for derby1252.diff
Old clients with new server return wrong database metadata values for some
methods
--
Key: DERBY-1252
URL: http://issues.apache.org/jira/browse/DERBY-1252
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1,
10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
Reporter: Dag H. Wanvik
Assigned To: Dag H. Wanvik
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby1252-10.1.diff, derby1252-10.1.stat,
derby1252.diff, derby1252.diff, derby1252.stat
With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
some metadata calls will return the wrong value for both the JCC and
the Derby clients:
deletesAreDetected(TYPE_SCROLL_INSENSITIVE) - true
updatedAreDetected(TYPE_SCROLL_INSENSITIVE) - true
ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
This happens because these values were changed for the 10.2 with
the addition of updatable scrollable insensitive result sets (DERBY-775),
combined with a weakness in the way the client and the server
cooperates to answer these metadata calls.
Presently, when the client application invokes these methods, the
results will be returned by the server without regard to the identity
of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
The values to be returned for the methods in question are based solely
on the values found in the file metadata_net.properties, which is part
of the server.
In general, some database metadata is dependent on the combination of
the capabilities in the client and the server and the returned values
should reflect this, which in general implies negotiating (down) to
values which are correct for the actual combination of client and
server.
--
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-1377) Update copyright headers to comply with new ASF policy
[ http://issues.apache.org/jira/browse/DERBY-1377?page=comments#action_12425045 ] David Van Couvering commented on DERBY-1377: Do we have any conclusion about how we should take care of this? I'm thinking of unassigning myself from this problem as I feel like I don't have the complete context, not being part of the team that originally contributed the code... Update copyright headers to comply with new ASF policy -- Key: DERBY-1377 URL: http://issues.apache.org/jira/browse/DERBY-1377 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.0.0 Reporter: Jean T. Anderson Assigned To: David Van Couvering Fix For: 10.2.0.0 A new copyright header policy will take effect for distributions released starting on Sep 1, 2006. Committers will receive notification, but a heads up with details is in the legal-discuss thread starting with http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] Date was 1-Aug-2006, is now 1-Sep-2006: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200607.mbox/[EMAIL PROTECTED] -- 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-1252) Old clients with new server return wrong database metadata values for some methods
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
-
Derby Info: [Patch Available, Existing Application Impact, Regression]
(was: [Existing Application Impact, Regression])
Old clients with new server return wrong database metadata values for some
methods
--
Key: DERBY-1252
URL: http://issues.apache.org/jira/browse/DERBY-1252
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1,
10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
Reporter: Dag H. Wanvik
Assigned To: Dag H. Wanvik
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby1252-10.1.diff, derby1252-10.1.stat,
derby1252.diff, derby1252.diff, derby1252.stat
With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
some metadata calls will return the wrong value for both the JCC and
the Derby clients:
deletesAreDetected(TYPE_SCROLL_INSENSITIVE) - true
updatedAreDetected(TYPE_SCROLL_INSENSITIVE) - true
ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) - true
This happens because these values were changed for the 10.2 with
the addition of updatable scrollable insensitive result sets (DERBY-775),
combined with a weakness in the way the client and the server
cooperates to answer these metadata calls.
Presently, when the client application invokes these methods, the
results will be returned by the server without regard to the identity
of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
The values to be returned for the methods in question are based solely
on the values found in the file metadata_net.properties, which is part
of the server.
In general, some database metadata is dependent on the combination of
the capabilities in the client and the server and the returned values
should reflect this, which in general implies negotiating (down) to
values which are correct for the actual combination of client and
server.
--
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-1417) Add new, lengthless overloads to the streaming api
[ http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12425048 ] Kristian Waagan commented on DERBY-1417: Thanks for looking at the patch, Rick :) I added the test case mostly to demonstrate the expected behavior. a) The user should never trip across this at all. If it is thrown, it must be because of a programming error in Derby. Currently, the byte arrays passed in are read from a user/application stream, and the bytes are counted as they are read. b) The user would see something ugly... For the non-debug version, replace the linenumbers with Unknown Source. The error is constructed. 1) testSetClobLengthless(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)java.lang.IllegalArgumentException: Length cannot be negative: -37 at org.apache.derby.client.am.ByteArrayCombinerStream.init(ByteArrayCombinerStream.java:78) at org.apache.derby.client.am.Lob.materializeStream(Lob.java:164) at org.apache.derby.client.am.Clob.materializeStream(Clob.java:833) at org.apache.derby.client.am.Clob.length(Clob.java:216) at org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(NetStatementRequest.java:1232) at org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(NetStatementRequest.java:520) at org.apache.derby.client.net.NetStatementRequest.writeExecute(NetStatementRequest.java:139) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPreparedStatement.java:171) at org.apache.derby.client.am.PreparedStatement.writeExecute(PreparedStatement.java:1543) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:1789) at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1347) at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1332) at org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest.testSetClobLengthless(PreparedStatementTest.java:375) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at org.apache.derbyTesting.functionTests.util.BaseTestCase.runBare(Unknown Source) I realize this does not look good, but it should not happen. I don't feel like making these two exceptions checked, or just ignore the error conditions (as the previous implementation did). Does anyone have opinions? Are there guidelines to follow? 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.0.0 Reporter: Rick Hillegas Assigned To: Kristian Waagan Fix For: 10.2.0.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 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)
[jira] Commented: (DERBY-1241) When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirr
[ http://issues.apache.org/jira/browse/DERBY-1241?page=comments#action_12425051 ] Andrew McIntyre commented on DERBY-1241: This is a pretty obvious fix for a serious problem. I think we should get this in for 10.2, even if writing a proper regression test for it won't happen till later. And, I see that Myrna has also filed a JIRA for that so it won't drop off the radar. Does anyone object to committing this patch? When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirror.ctrl if database was not shutdown cleanly after previous access -- Key: DERBY-1241 URL: http://issues.apache.org/jira/browse/DERBY-1241 Project: Derby Issue Type: Bug Components: Store Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-1241_20060801.diff, derby_tests.policy logmirror.ctrl is getting accessed outside the privileged block when the checkpoint instant is invalid on log factory boot method and cause this failure on boot if the database was not shutdown cleanly. The reproduction (see comment) shows that can happens after database creation. This problem was reported on the derby-dev list by Olav Sandstaa , filing jira entry for it. Olav Sandstaa wrote: Rick Hillegas [EMAIL PROTECTED] wrote: java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission /export/home/tmp/derbyjdbc4/DerbyNetClient/TestConnectionMethods/wombat/log/logmirror.ctrl read): java.security.AccessControlException'. at java.security.AccessControlContext.checkPermission(AccessControlContext.java:321) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:731) at org.apache.derby.impl.store.raw.log.LogToFile.boot(LogToFile.java:2940) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(BaseDataFileFactory.java:1762) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(BaseDataFileFactory.java:1218) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:250) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:987) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:738) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:178) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1831) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1697) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1577) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541) at
Re: [jira] Commented: (DERBY-1241) When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for log
patch looks good to me - one line change seems obvious fix, and looks like what suresh suggested was probably the fix. Since it fixes the by hand check case I say check it in, even if no new test. Andrew McIntyre (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1241?page=comments#action_12425051 ] Andrew McIntyre commented on DERBY-1241: This is a pretty obvious fix for a serious problem. I think we should get this in for 10.2, even if writing a proper regression test for it won't happen till later. And, I see that Myrna has also filed a JIRA for that so it won't drop off the radar. Does anyone object to committing this patch? When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirror.ctrl if database was not shutdown cleanly after previous access -- Key: DERBY-1241 URL: http://issues.apache.org/jira/browse/DERBY-1241 Project: Derby Issue Type: Bug Components: Store Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-1241_20060801.diff, derby_tests.policy logmirror.ctrl is getting accessed outside the privileged block when the checkpoint instant is invalid on log factory boot method and cause this failure on boot if the database was not shutdown cleanly. The reproduction (see comment) shows that can happens after database creation. This problem was reported on the derby-dev list by Olav Sandstaa , filing jira entry for it. Olav Sandstaa wrote: Rick Hillegas [EMAIL PROTECTED] wrote: java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission /export/home/tmp/derbyjdbc4/DerbyNetClient/TestConnectionMethods/wombat/log/logmirror.ctrl read): java.security.AccessControlException'. at java.security.AccessControlContext.checkPermission(AccessControlContext.java:321) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:731) at org.apache.derby.impl.store.raw.log.LogToFile.boot(LogToFile.java:2940) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(BaseDataFileFactory.java:1762) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(BaseDataFileFactory.java:1218) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:250) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:987) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:738) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:178) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1831) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1697) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1577) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541) at
Building Derby
Hi,I ran across an interesting issue while building Derby. I checked out the latest sources and ran ant from the top. I read the ant output and found this:genParser: [echo] Generating SQL parser... [java] Java Compiler Compiler Version 4.0 (Parser Generator) [java] (type "javacc" with no arguments for help) [java] Reading from file sqlgrammar.jj . . . [java] Note: UNICODE_INPUT option is specified. Please make sure you create the parser/lexer using a Reader with the correct character encoding. [java] Warning: ParseException.java: File is obsolete. Please rename or delete this file so that a new one can be generated for you. [java] Warning: Token.java: File is obsolete. Please rename or delete this file so that a new one can be generated for you. [java] Warning: CharStream.java: File is obsolete. Please rename or delete this file so that a new one can be generated for you. [java] Parser generated with 0 errors and 3 warnings.Thinking I had done something wrong, I followed instructions and removed the 3 obsolete files. Now I could not build any more. I got messages like this:genParser:compile: [javac] Compiling 149 source files to /Users/clr/derby/trunk/classes [javac] /Users/clr/derby/trunk/java/engine/org/apache/derby/impl/sql/compile/ParserImpl.java:141: cannot find symbol [javac] symbol : method ReInit(java.io.Reader,int,int,int) [javac] location: interface org.apache.derby.impl.sql.compile.CharStream [javac] charStream.ReInit(sqlText, 1, 1, LARGE_TOKEN_SIZE);Once I went back and restored the three files to their checked-in versions, everything worked again.This indicates to me that the sources for these three files in sqlgrammar.jj are not in sync with the generated java files. Was this intentional? Should we add a note in BUILDING.txt to explain what is going on?Thanks,Craig Craig Russell[EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: [jira] Updated: (DERBY-1579) Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality
On 8/1/06, Yip Ng (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1579?page=all ] Yip Ng updated DERBY-1579: -- Attachment: derby1579trunkstat02.txt derby1579trunkdiff02.txt Resubmitting patch - derby1579trunkdiff02.txt Thanks Yip for uploading an updated patch. It applies cleanly in my workspace. I plan to run derbyall later tonight with this new patch. Thanks, Deepa
[jira] Updated: (DERBY-1530) DatabaseMetaData.getFunctionParameters() changing name to getFunctionColumns()
[ http://issues.apache.org/jira/browse/DERBY-1530?page=all ] Rick Hillegas updated DERBY-1530: - Attachment: derby-1530_v01.diff Attaching derby-1530_v01.diff, which makes the following changes: 1) Renames getFunctionParameters() as getFunctionColumns() 2) Renames the functionParameter* constants to functionColumn* 3) Renames 2 of the columns returned by getFunctionColumns() from PARAMATER_* to COLUMN_*. 4) Makes corresponding changes to tests and test output. Touches the following files: M java/engine/org/apache/derby/impl/jdbc/metadata.properties M java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java M java/engine/org/apache/derby/catalog/SystemProcedures.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/metadata_test.java M java/testing/org/apache/derbyTesting/functionTests/master/metadata.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/metadata.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/odbc_metadata.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk14/metadata.out M java/testing/org/apache/derbyTesting/functionTests/master/Upgrade_10_1_10_2.out M java/testing/org/apache/derbyTesting/functionTests/master/odbc_metadata.out M java/testing/org/apache/derbyTesting/functionTests/master/TestDbMetaData.out M java/client/org/apache/derby/client/am/DatabaseMetaData.java This patch can't be committed until the corresponding JDBC4 changes turn up in the Mustang beta. DatabaseMetaData.getFunctionParameters() changing name to getFunctionColumns() -- Key: DERBY-1530 URL: http://issues.apache.org/jira/browse/DERBY-1530 Project: Derby Issue Type: New Feature Components: JDBC Affects Versions: 10.2.0.0 Reporter: Rick Hillegas Assigned To: Rick Hillegas Fix For: 10.2.0.0 Attachments: derby-1530_v01.diff The JDBC4 expert group has made the following changes to their spec: DatabaseMetaData.getFunctionParameters() is changing name to getFunctionColumns() The DatabaseMetaData.functionParameter* constants are changing name to functionColumn* -- 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
Unexplained diff in procedureInTrigger.sql for JDK 1.6
Hi, all. In evaluating diffs currently happening in JDK 1.6 derbyall, I
ran across this strange diff:
398d397
ERROR 38000: The exception 'java.sql.SQLException: The external
routine is not allowed to execute SQL statements.' was thrown while
evaluating an expression.
Basically what is happening is in JDK 1.6 Derby is not wrapping 38001
inside 38000. The reason? Well, in JDK 1.6, Derby public methods
throws SQLExceptions that are *not* a subclass of EmbedSQLException.
This results in different logic in the method
StandardException.unexpectedUserException():
public static StandardException unexpectedUserException(Throwable t)
{
/*
** If we have a SQLException that isn't a Util
** (i.e. it didn't come from cloudscape), then we check
** to see if it is a valid user defined exception range
** (38001-38XXX). If so, then we convert it into a
** StandardException without further ado.
*/
if ((t instanceof SQLException)
!(t instanceof EmbedSQLException))
{
SQLException sqlex = (SQLException)t;
String state = sqlex.getSQLState();
if ((state != null)
(state.length() == 5)
state.startsWith(38)
!state.equals(38000))
{
StandardException se = new
StandardException(state, sqlex.getMessage());
if (sqlex.getNextException() != null)
{
se.setNestedException(sqlex.getNextException());
}
return se;
}
}
So, my question is, should I codify this by creating a jdk16 master file
for procedureInTrigger.sql? Or is this something we need to try and
address?
What also is curious is that this should have shown up elsewhere. I'm
noticing a lot of other JDK 1.6-specific master files -- maybe this is
part of it?
Thanks,
David
[jira] Resolved: (DERBY-1241) When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirro
[ http://issues.apache.org/jira/browse/DERBY-1241?page=all ] Andrew McIntyre resolved DERBY-1241. Resolution: Fixed Derby Info: (was: [Patch Available]) Verified manual test case. Committed to trunk with revision 427796. Seems like a good candidate for merging to 10.1 also. When booting a database under security manager, boot may fail with message java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission for logmirror.ctrl if database was not shutdown cleanly after previous access -- Key: DERBY-1241 URL: http://issues.apache.org/jira/browse/DERBY-1241 Project: Derby Issue Type: Bug Components: Store Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Priority: Critical Fix For: 10.2.0.0 Attachments: DERBY-1241_20060801.diff, derby_tests.policy logmirror.ctrl is getting accessed outside the privileged block when the checkpoint instant is invalid on log factory boot method and cause this failure on boot if the database was not shutdown cleanly. The reproduction (see comment) shows that can happens after database creation. This problem was reported on the derby-dev list by Olav Sandstaa , filing jira entry for it. Olav Sandstaa wrote: Rick Hillegas [EMAIL PROTECTED] wrote: java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission /export/home/tmp/derbyjdbc4/DerbyNetClient/TestConnectionMethods/wombat/log/logmirror.ctrl read): java.security.AccessControlException'. at java.security.AccessControlContext.checkPermission(AccessControlContext.java:321) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:731) at org.apache.derby.impl.store.raw.log.LogToFile.boot(LogToFile.java:2940) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(BaseDataFileFactory.java:1762) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(BaseDataFileFactory.java:1218) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:250) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:987) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:738) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:178) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1831) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1697) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1577) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1586) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:216) at
Re: Building Derby
These error messages are to be expected. I agree BUILDING.txt should warn people to expect this, I agree it is disconcerting. David Craig L Russell wrote: Hi, I ran across an interesting issue while building Derby. I checked out the latest sources and ran ant from the top. I read the ant output and found this: genParser: [echo] Generating SQL parser... [java] Java Compiler Compiler Version 4.0 (Parser Generator) [java] (type javacc with no arguments for help) [java] Reading from file sqlgrammar.jj . . . [java] Note: UNICODE_INPUT option is specified. Please make sure you create the parser/lexer using a Reader with the correct character encoding. [java] Warning: ParseException.java: File is obsolete. Please rename or delete this file so that a new one can be generated for you. [java] Warning: Token.java: File is obsolete. Please rename or delete this file so that a new one can be generated for you. [java] Warning: CharStream.java: File is obsolete. Please rename or delete this file so that a new one can be generated for you. [java] Parser generated with 0 errors and 3 warnings. Thinking I had done something wrong, I followed instructions and removed the 3 obsolete files. Now I could not build any more. I got messages like this: genParser: compile: [javac] Compiling 149 source files to /Users/clr/derby/trunk/classes [javac] /Users/clr/derby/trunk/java/engine/org/apache/derby/impl/sql/compile/ParserImpl.java:141: cannot find symbol [javac] symbol : method ReInit(java.io.Reader,int,int,int) [javac] location: interface org.apache.derby.impl.sql.compile.CharStream [javac] charStream.ReInit(sqlText, 1, 1, LARGE_TOKEN_SIZE); Once I went back and restored the three files to their checked-in versions, everything worked again. This indicates to me that the sources for these three files in sqlgrammar.jj are not in sync with the generated java files. Was this intentional? Should we add a note in BUILDING.txt to explain what is going on? Thanks, Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo
Re: Unexplained diff in procedureInTrigger.sql for JDK 1.6
David Van Couvering wrote:
Hi, all. In evaluating diffs currently happening in JDK 1.6 derbyall, I
ran across this strange diff:
398d397
ERROR 38000: The exception 'java.sql.SQLException: The external
routine is not allowed to execute SQL statements.' was thrown while
evaluating an expression.
Basically what is happening is in JDK 1.6 Derby is not wrapping 38001
inside 38000. The reason? Well, in JDK 1.6, Derby public methods
throws SQLExceptions that are *not* a subclass of EmbedSQLException.
This results in different logic in the method
StandardException.unexpectedUserException():
public static StandardException unexpectedUserException(Throwable t)
{
/*
** If we have a SQLException that isn't a Util
** (i.e. it didn't come from cloudscape), then we check
** to see if it is a valid user defined exception range
** (38001-38XXX). If so, then we convert it into a
** StandardException without further ado.
*/
if ((t instanceof SQLException)
!(t instanceof EmbedSQLException))
{
SQLException sqlex = (SQLException)t;
String state = sqlex.getSQLState();
if ((state != null)
(state.length() == 5)
state.startsWith(38)
!state.equals(38000))
{
StandardException se = new StandardException(state,
sqlex.getMessage());
if (sqlex.getNextException() != null)
{
se.setNestedException(sqlex.getNextException());
}
return se;
}
}
So, my question is, should I codify this by creating a jdk16 master file
for procedureInTrigger.sql? Or is this something we need to try and
address?
I think that's a bug. The comment indicates the code is determining if
the error was raised by Derby (nee Cloudscape), if so handle it
according to the SQL standard. The check for EmbedSQLException is no
longer sufficient with the JDBC 4 changes.
Dan.
[jira] Commented: (DERBY-1489) Provide ALTER TABLE DROP COLUMN functionality
[ http://issues.apache.org/jira/browse/DERBY-1489?page=comments#action_12425063 ] Bryan Pendleton commented on DERBY-1489: Thanks for the review, Rick! I will work on investigating the issues you raised. Provide ALTER TABLE DROP COLUMN functionality - Key: DERBY-1489 URL: http://issues.apache.org/jira/browse/DERBY-1489 Project: Derby Issue Type: New Feature Components: Documentation, SQL Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Bryan Pendleton Assigned To: Bryan Pendleton Fix For: 10.2.0.0 Attachments: dropColumn_2.diff Provide a way to drop a column from an existing table. Possible syntax would be: ALTER TABLE tablename DROP COLUMN columnname CASCADE / RESTRICT; Feature should properly handle columns which are used in constraints, views, triggers, indexes, etc. -- 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-119) Add ALTER TABLE option to change column from NULL to NOT NULL
[ http://issues.apache.org/jira/browse/DERBY-119?page=comments#action_12425064 ] Bryan Pendleton commented on DERBY-119: --- Thank you very much for the review, Deepa. I will investigate the issues that you raised. Add ALTER TABLE option to change column from NULL to NOT NULL - Key: DERBY-119 URL: http://issues.apache.org/jira/browse/DERBY-119 Project: Derby Issue Type: New Feature Components: SQL Reporter: Bernd Ruehlicke Assigned To: Bryan Pendleton Attachments: alterColumnNotNull_1.diff There was a thread about this on the Cloudscape forum http://www-106.ibm.com/developerworks/forums/dw_thread.jsp?message=4103269cat=19thread=59941forum=370#4103269 Since this describes the problem I will just copy the content of this entry as my dexscription The content of this was Hi, I stumbled across a behaviour of cloudscape which is not a bug but IMHO an implementation choice. To assign a primary key to a table using ALTER TABLE all columns must be declared NOT NULL first, which can only be specified upon column creation (no ALTER TABLE statement exists to change the NOT NULL property of a column). Most databases I know do two things differently: 1) when a primary key is assigned all pk columns are automatically set to NOT NULL, if one of them contains NULL values, the ALTER TABLE statement fails 2) it is possible to alter the column to set the NOT NULL property after column creation (fails when there are already records containing NULL values) If I have understood the limitations correctly in Cloudscape I have no choice but to remove and re-add the column which is supposed to be used in the primary key, if it is not already declared as NOT NULL. This means that in the case of a table containing valid data (unique and not null) in the column in all records, I would have to export the data, remove and re-add the column and reimport that data, which would not be necessary e.g. in Oracle or MaxDB. Is it possible to change that behaviour or is there a good reason for it? It looks as if it makes the life of the user more difficult than necessary for certain metadata manipulations. Making it possible to alter the NOT NULL property of a column would solve this and IMHO having a primary key constraint do this implicitly makes sense as well. Thanks in advance for any insight on this, Robert -- 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
