Re: Re: LineNumber table in class files and sane=false strangeness
On 8/21/06, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote: Don't you have to set debug=true/false as well? Insane with line numbers:ant -Dsane=false -Ddebug=true Insane without line numbers: ant -Dsane=false -Ddebug=false Sane with line numbers: ant -Dsane=true -Ddebug=true Sane without line numbers: ant -Dsane=true -Ddebug=false You shouldn't need to. The default behavior is for insane to compile without line numbers and for sane to compile with line numbers, accomplished via the settings in sane(false|true).properties in tools/ant/properties. You can override that behavior by passing in the debug flag on the command line. The problem fixed with the patch attached to DERBY-744 would lead to sane being set to true, even if it was passed in as false in a properties file or in some circumstances on the command-line. The workaround was to run 'ant insane', which bypassed the incorrect use of the condition that led to sane being set to true during the init phase of the build. andrew
Re: LineNumber table in class files and sane=false strangeness
Daniel John Debrunner <[EMAIL PROTECTED]> writes: > I'm trying to figure out when one of my derby codelines compiles with > LineNumber tables and one without. They have identical ant.properties > files that I use to build, with sane=false. Compling an individual file > shows the -g:none flag being used in both cases, but I end up with class > files of vastly different sizes from an: > > ant clobber > ant all > > In the bigger classes I can dump the raw format and see the line number > table is in there, in the smaller ones it seems to be missing. E.g. > > First codeline > > 2746 PermissionsCatalogRowFactory.class > > Second codeline > > 2116 PermissionsCatalogRowFactory.class > > If I remove PermissionsCatalogRowFactory.class and recompile just using > ant from the top level then it reverts to 2116 bytes in the first codeline. > > Doing a ant clobber followed by an ant -verbose all in the first > codeline reveals this as the only entry for that class. > > [javac] > org\apache\derby\impl\sql\catalog\PermissionsCatalogRowFactory.java > omitted as > org/apache/derby/impl/sql/catalog/PermissionsCatalogRowFactory.class is > up to date. > > So I assume something else is compiling it indirectly with a different > -g flag, that doesn't match my sane=false setting, any ideas? Don't you have to set debug=true/false as well? Insane with line numbers:ant -Dsane=false -Ddebug=true Insane without line numbers: ant -Dsane=false -Ddebug=false Sane with line numbers: ant -Dsane=true -Ddebug=true Sane without line numbers: ant -Dsane=true -Ddebug=false -- Knut Anders
[jira] Created: (DERBY-1743) derbynet/testSecMec.java fails with NullPointerException (intermittent failure)
derbynet/testSecMec.java fails with NullPointerException (intermittent failure) --- Key: DERBY-1743 URL: http://issues.apache.org/jira/browse/DERBY-1743 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.0.0 Environment: Solaris 10 x86, Sun JVM 1.5.0_04 Reporter: Knut Anders Hatlen http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/433374-derbyall_diff.txt * Diff file derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/testSecMec.diff *** Start: testSecMec jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-08-22 01:45:28 *** 61a62,63 > java.sql.SQLException: No current connection. > Exception in thread "DRDAConnThread_15" java.lang.NullPointerException Test Failed. *** End: testSecMec jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-08-22 01:46:05 *** Detailed log: Test USRSSBPWD_with_BUILTIN - derby.drda.securityMechanism=null Turning ON Derby BUILTIN authentication USRSSBPWD (T0): jdbc:derby://localhost:2/wombat;user=neelima;password=lee;shutdown=true;securityMechanism=8 - EXCEPTION DERBY SQL error: SQLCODE: -1, SQLSTATE: 08006, SQLERRMC: Database 'wombat' shutdown. java.sql.SQLException: No current connection. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.rollback(Unknown Source) at org.apache.derby.impl.drda.Database.close(Unknown Source) at org.apache.derby.impl.drda.Session.close(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.closeSession(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) Exception in thread "DRDAConnThread_15" java.lang.NullPointerException at java.lang.Throwable.printStackTrace(Throwable.java:509) at org.apache.derby.impl.drda.DRDAProtocolException.(Unknown Source) at org.apache.derby.impl.drda.DRDAProtocolException.newAgentError(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.sendUnexpectedException(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.closeSession(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) -- 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: JDBC4 build failing for me
David Van Couvering <[EMAIL PROTECTED]> writes: > Well, that doesn't fully make sense, since nobody else seems to be > complaining about this. Wouldn't we get build failures in the > regression nightlies and other JDBC4 developers if this were a global > issue? I've had this problem for two days now... Well, that's strange since Rick checked in a fix 11 days ago. Looking at the error messages, it seems like your source tree is not up to date. Have you considered 'svn up' followed by 'ant testing' and 'ant buildjars'? :) -- Knut Anders
Regression Test Failure! - TinderBox_Derby 433449 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 433449/2006-08-22 03:12:59 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2672670 2 151.23% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-433449.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/433449.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/433449.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
10.2.1 beta candidate testing results SLES 9 and Windows 2003 Server
Rajesh Kartha wrote: Hi, I have been running some tests on the 10.2.1.0 beta candidate and was thinking of a single place for posting all the results related to this round of beta testing. = = = SNIP = = = I've posted the results of my testing (running derbyall), with links to the bugs encountered at: http://wiki.apache.org/db-derby/TenTwoPlatformTesting Most, but not all, of the failures appear to be problems with the Test system or JVM specific. The following summarizes the derbyall test results by platform tested [NOTE about failure counts: some problems were encountered by multiple tests, e.g. The test system problem Derby-1221 was encountered 14 times]: SLES 9 Win2003 Win2003 ibm131ibm15 sun15 Tests Total629 693 693 Tests Passed 616 670 688 Tests Skipped 8 2 2 Test Failed621 3
[jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12429588 ] Bryan Pendleton commented on DERBY-688: --- Does the phase6 patch need to be applied to the 10.2 branch? > Enhancements to XML functionality to move toward XPath/XQuery support... > > > Key: DERBY-688 > URL: http://issues.apache.org/jira/browse/DERBY-688 > Project: Derby > Issue Type: Improvement > Components: JDBC, SQL >Reporter: A B > Assigned To: A B >Priority: Minor > Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, > d688_phase1_v2.patch, d688_phase1_v3.patch, d688_phase2_v1_code.patch, > d688_phase2_v1_tests.patch, d688_phase2_v2_tests.patch, > d688_phase2_v3_tests.patch, d688_phase3_v1_code.patch, > d688_phase3_v1_tests.patch, d688_phase4_v1.patch, d688_phase4_v2.patch, > d688_phase5_v1.patch, d688_phase6_v1.patch, derbyXMLSpec.html > > > As of DERBY-334, Derby has some very basic support for XML that consists of > an XML datatype and three operators (XMLPARSE, XMLSERIALIZE, and XMLEXISTS). > I would like to enhance this existing functionality and, by doing so, help to > move Derby incrementally toward a more usable and more complete XPath/XQuery > solution (with emphasis on "incrementally"). > I have attached to this issue a document describing the particular changes > that I am looking to make. At a high level, they consist of: > 1) Making it easier to use the XML operators and datatype from within JDBC > (ex. by implicit parsing/serialization of XML values). > 2) Adding a new operator, XMLQUERY, to allow a user to retrieve the results > of an XPath expression (instead of just determining whether or not the > expression evaluates to an empty sequence, which is what XMLEXISTS does). > 3) Making changes to the existing operators to line them up with the SQL/XML > 2005 specification, and also to take steps toward my eventual hope of having > support for XQuery (as opposed to just XPath) in Derby. > If anyone has time and interest enough to look at the document and provide > feedback, that'd be great... -- 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: JDBC4 build failing for me
Well, that doesn't fully make sense, since nobody else seems to be complaining about this. Wouldn't we get build failures in the regression nightlies and other JDBC4 developers if this were a global issue? I've had this problem for two days now... David Lance J. Andersen wrote: Hi David, There were changes in this area to the DatabaseMetaData and it looks like this test might not have caught up to it. -lance David Van Couvering wrote: I am running with the latest drop from the jdk 1.6 site, and I have the latest stuff from the trunk, and I am getting the following errors. These appear to be members of java.sql.DatabaseMetaData. I am hoping someone familiar with this area of the code can provide some quick guidance... Thanks, David === [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:39: cannot find symbol [javac] symbol : variable functionParameterUnknown [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterUnknown, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:44: cannot find symbol [javac] symbol : variable functionParameterIn [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterIn, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:49: cannot find symbol [javac] symbol : variable functionParameterInOut [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterInOut, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:99: cannot find symbol [javac] symbol : variable functionParameterUnknown [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterUnknown)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:101: cannot find symbol [javac] symbol : variable functionParameterIn [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterIn)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:103: cannot find symbol [javac] symbol : variable functionParameterInOut [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterInOut)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:105: cannot find symbol [javac] symbol : variable functionParameterOut [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterOut)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:157: cannot find symbol [javac] symbol : method getFunctionParameters(,,java.lang.String,) [javac] location: interface java.sql.DatabaseMetaData [javac] dumpRS(met.getFunctionParameters(null,null,"DUMMY%",null)); [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:160: cannot find symbol [javac] symbol : method getFunctionParameters(,,java.lang.String,java.lang.String) [javac] location: interface java.sql.DatabaseMetaData [javac] dumpRS(met.getFunctionParameters(null,null,"DUMMY%","")); [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 9 errors BUILD FAILED /export/home/dv136566/derby/patch/trunk/build.xml:336: The following error occurred while executing this line: /export/home/dv136566/derby/patch/trunk/java/testing/build.xml:75: The following error occurred while executing this line: /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/build.xml:64: Compile failed; see the compiler error output for details.
Should DERBY-231 fix DERBY-142 ?
The Torque tutorial (http://db.apache.org/derby/integrate/db_torque.html) works with Derby using the embedded jdbc driver but not using the derby network client jdbc driver (DERBY-142). When I verified last week that the Torque tutorial still works with Derby 10.2 (and it did), I hoped it would now also work with the derby client driver because of DERBY-231, but it didn't. >From a superficial glance at DERBY-142, do you think that it should have been fixed? If so, I'll dig some more. thanks, -jean
Re: JDBC4 build failing for me
H, so Rick wrote on 8/11: > Build 95 should be the last Mustang version which changes JDBC signatures. David wrote: (today) > Java(TM) SE Runtime Environment (build 1.6.0-rc-b96) Lance wrote: (today) >> There were changes in this area to the DatabaseMetaData and it looks >> like this test might not have caught up to it. So, do we have a new target build number for Mustang where it is expected (hoped) that the JDBC 4.0 signatures, constants, classes etc. do not change? Dan.
[jira] Updated: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ] Bryan Pendleton updated DERBY-688: -- Derby Info: (was: [Patch Available]) I reviewed d688_phase6_v1.patch and it looks good to me. The build was fine, and derbyall ran cleanly. xml_general.sql and xmlBinding.java ran as expected with Xalan 2.7. Committed this patch to subversion as revision 433450, and cleared the PatchAvailable flag. > Enhancements to XML functionality to move toward XPath/XQuery support... > > > Key: DERBY-688 > URL: http://issues.apache.org/jira/browse/DERBY-688 > Project: Derby > Issue Type: Improvement > Components: JDBC, SQL >Reporter: A B > Assigned To: A B >Priority: Minor > Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, > d688_phase1_v2.patch, d688_phase1_v3.patch, d688_phase2_v1_code.patch, > d688_phase2_v1_tests.patch, d688_phase2_v2_tests.patch, > d688_phase2_v3_tests.patch, d688_phase3_v1_code.patch, > d688_phase3_v1_tests.patch, d688_phase4_v1.patch, d688_phase4_v2.patch, > d688_phase5_v1.patch, d688_phase6_v1.patch, derbyXMLSpec.html > > > As of DERBY-334, Derby has some very basic support for XML that consists of > an XML datatype and three operators (XMLPARSE, XMLSERIALIZE, and XMLEXISTS). > I would like to enhance this existing functionality and, by doing so, help to > move Derby incrementally toward a more usable and more complete XPath/XQuery > solution (with emphasis on "incrementally"). > I have attached to this issue a document describing the particular changes > that I am looking to make. At a high level, they consist of: > 1) Making it easier to use the XML operators and datatype from within JDBC > (ex. by implicit parsing/serialization of XML values). > 2) Adding a new operator, XMLQUERY, to allow a user to retrieve the results > of an XPath expression (instead of just determining whether or not the > expression evaluates to an empty sequence, which is what XMLEXISTS does). > 3) Making changes to the existing operators to line them up with the SQL/XML > 2005 specification, and also to take steps toward my eventual hope of having > support for XQuery (as opposed to just XPath) in Derby. > If anyone has time and interest enough to look at the document and provide > feedback, that'd be great... -- 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: JDBC4 build failing for me
Hi David, There were changes in this area to the DatabaseMetaData and it looks like this test might not have caught up to it. -lance David Van Couvering wrote: I am running with the latest drop from the jdk 1.6 site, and I have the latest stuff from the trunk, and I am getting the following errors. These appear to be members of java.sql.DatabaseMetaData. I am hoping someone familiar with this area of the code can provide some quick guidance... Thanks, David === [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:39: cannot find symbol [javac] symbol : variable functionParameterUnknown [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterUnknown, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:44: cannot find symbol [javac] symbol : variable functionParameterIn [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterIn, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:49: cannot find symbol [javac] symbol : variable functionParameterInOut [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterInOut, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:99: cannot find symbol [javac] symbol : variable functionParameterUnknown [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterUnknown)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:101: cannot find symbol [javac] symbol : variable functionParameterIn [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterIn)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:103: cannot find symbol [javac] symbol : variable functionParameterInOut [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterInOut)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:105: cannot find symbol [javac] symbol : variable functionParameterOut [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterOut)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:157: cannot find symbol [javac] symbol : method getFunctionParameters(,,java.lang.String,) [javac] location: interface java.sql.DatabaseMetaData [javac] dumpRS(met.getFunctionParameters(null,null,"DUMMY%",null)); [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:160: cannot find symbol [javac] symbol : method getFunctionParameters(,,java.lang.String,java.lang.String) [javac] location: interface java.sql.DatabaseMetaData [javac] dumpRS(met.getFunctionParameters(null,null,"DUMMY%","")); [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 9 errors BUILD FAILED /export/home/dv136566/derby/patch/trunk/build.xml:336: The following error occurred while executing this line: /export/home/dv136566/derby/patch/trunk/java/testing/build.xml:75: The following error occurred while executing this line: /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/build.xml:64: Compile failed; see the compiler error output for details.
Regression Test Failure! - TinderBox_Derby 433374 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 433374/2006-08-21 23:53:00 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2672670 2 151.85% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-433374.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/433374.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/433374.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Updated: (DERBY-744) Problem setting sanity state to false by using 'ant -Dsane=false'
[ http://issues.apache.org/jira/browse/DERBY-744?page=all ] Daniel John Debrunner updated DERBY-744: Fix Version/s: 10.3.0.0 (was: 10.2.2.0) Changes made in 10.3 in trunk, may be good to merge up to 10.2 > Problem setting sanity state to false by using 'ant -Dsane=false' > - > > Key: DERBY-744 > URL: http://issues.apache.org/jira/browse/DERBY-744 > Project: Derby > Issue Type: Bug > Components: Build tools >Affects Versions: 10.2.1.0, 10.1.2.1, 10.1.3.0, 10.1.2.2 >Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: derby-744-v1.diff > > > Problem report from Kathey Marsden: > There seems to be some sort of problem with the sanity state. > After ant clobber, rm -rf jars, rm -rf snapshot no apparent problematic > files, ant -Dsane=false snapshot seemed to sometimes build the jars to > the sane jar directory and yield the following error. > > [delete] Deleting directory D:\svn\opensource\10.1\javadoc\sourcedir >[mkdir] Created dir: D:\svn\opensource\10.1\snapshot > BUILD FAILED > D:\svn\opensource\10.1\build.xml:1287: > D:\svn\opensource\10.1\jars\insane not found. > A reliable workaround was to run > ant insane > before ant -Dsane=false snapshot. -- 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-744) Problem setting sanity state to false by using 'ant -Dsane=false'
[ http://issues.apache.org/jira/browse/DERBY-744?page=comments#action_12429575 ] Daniel John Debrunner commented on DERBY-744: - I also committed the change that makes the top-level demo targt depend on buildsource - revision 433445 > Problem setting sanity state to false by using 'ant -Dsane=false' > - > > Key: DERBY-744 > URL: http://issues.apache.org/jira/browse/DERBY-744 > Project: Derby > Issue Type: Bug > Components: Build tools >Affects Versions: 10.2.1.0, 10.1.2.1, 10.1.3.0, 10.1.2.2 >Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: derby-744-v1.diff > > > Problem report from Kathey Marsden: > There seems to be some sort of problem with the sanity state. > After ant clobber, rm -rf jars, rm -rf snapshot no apparent problematic > files, ant -Dsane=false snapshot seemed to sometimes build the jars to > the sane jar directory and yield the following error. > > [delete] Deleting directory D:\svn\opensource\10.1\javadoc\sourcedir >[mkdir] Created dir: D:\svn\opensource\10.1\snapshot > BUILD FAILED > D:\svn\opensource\10.1\build.xml:1287: > D:\svn\opensource\10.1\jars\insane not found. > A reliable workaround was to run > ant insane > before ant -Dsane=false snapshot. -- 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-744) Problem setting sanity state to false by using 'ant -Dsane=false'
[ http://issues.apache.org/jira/browse/DERBY-744?page=comments#action_12429574 ] Daniel John Debrunner commented on DERBY-744: - Patch derby-744-v1.diff committed revision 433443. Thanks Andrew. Seemed to solve the problem I was having with classes being built in sane mode when sane=false in ant.properties. > Problem setting sanity state to false by using 'ant -Dsane=false' > - > > Key: DERBY-744 > URL: http://issues.apache.org/jira/browse/DERBY-744 > Project: Derby > Issue Type: Bug > Components: Build tools >Affects Versions: 10.2.1.0, 10.1.2.1, 10.1.3.0, 10.1.2.2 >Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre >Priority: Minor > Fix For: 10.2.2.0 > > Attachments: derby-744-v1.diff > > > Problem report from Kathey Marsden: > There seems to be some sort of problem with the sanity state. > After ant clobber, rm -rf jars, rm -rf snapshot no apparent problematic > files, ant -Dsane=false snapshot seemed to sometimes build the jars to > the sane jar directory and yield the following error. > > [delete] Deleting directory D:\svn\opensource\10.1\javadoc\sourcedir >[mkdir] Created dir: D:\svn\opensource\10.1\snapshot > BUILD FAILED > D:\svn\opensource\10.1\build.xml:1287: > D:\svn\opensource\10.1\jars\insane not found. > A reliable workaround was to run > ant insane > before ant -Dsane=false snapshot. -- 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: JDBC4 build failing for me
I just double-checked, and in ~/ant.properties I have jdk16=/usr/jdk/jdk1.6.0 and then: bash-3.00$ /usr/jdk/jdk1.6.0/bin/java -version java version "1.6.0-rc" Java(TM) SE Runtime Environment (build 1.6.0-rc-b96) Java HotSpot(TM) Client VM (build 1.6.0-rc-b96, mixed mode, sharing) Which is the latest build of JDK 1.6... David David Van Couvering wrote: I am running with the latest drop from the jdk 1.6 site, and I have the latest stuff from the trunk, and I am getting the following errors. These appear to be members of java.sql.DatabaseMetaData. I am hoping someone familiar with this area of the code can provide some quick guidance... Thanks, David === [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:39: cannot find symbol [javac] symbol : variable functionParameterUnknown [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterUnknown, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:44: cannot find symbol [javac] symbol : variable functionParameterIn [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterIn, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:49: cannot find symbol [javac] symbol : variable functionParameterInOut [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterInOut, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:99: cannot find symbol [javac] symbol : variable functionParameterUnknown [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterUnknown)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:101: cannot find symbol [javac] symbol : variable functionParameterIn [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterIn)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:103: cannot find symbol [javac] symbol : variable functionParameterInOut [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterInOut)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:105: cannot find symbol [javac] symbol : variable functionParameterOut [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterOut)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:157: cannot find symbol [javac] symbol : method getFunctionParameters(,,java.lang.String,) [javac] location: interface java.sql.DatabaseMetaData [javac] dumpRS(met.getFunctionParameters(null,null,"DUMMY%",null)); [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:160: cannot find symbol [javac] symbol : method getFunctionParameters(,,java.lang.String,java.lang.String) [javac] location: interface java.sql.DatabaseMetaData [javac] dumpRS(met.getFunctionParameters(null,null,"DUMMY%","")); [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 9 errors BUILD FAILED /export/home/dv136566/derby/patch/trunk/build.xml:336: The following error occurred while executing this line: /export/home/dv136566/derby/patch/trunk/java/testing/build.xml:75: The following error occurred while executing this line: /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/build.xml:64: Compile failed; see the compiler error output for details.
JDBC4 build failing for me
I am running with the latest drop from the jdk 1.6 site, and I have the latest stuff from the trunk, and I am getting the following errors. These appear to be members of java.sql.DatabaseMetaData. I am hoping someone familiar with this area of the code can provide some quick guidance... Thanks, David === [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:39: cannot find symbol [javac] symbol : variable functionParameterUnknown [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterUnknown, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:44: cannot find symbol [javac] symbol : variable functionParameterIn [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterIn, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC40TranslationTest.java:49: cannot find symbol [javac] symbol : variable functionParameterInOut [javac] location: interface java.sql.DatabaseMetaData [javac] assertEquals(DatabaseMetaData.functionParameterInOut, [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:99: cannot find symbol [javac] symbol : variable functionParameterUnknown [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterUnknown)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:101: cannot find symbol [javac] symbol : variable functionParameterIn [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterIn)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:103: cannot find symbol [javac] symbol : variable functionParameterInOut [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterInOut)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:105: cannot find symbol [javac] symbol : variable functionParameterOut [javac] location: interface java.sql.DatabaseMetaData [javac] DatabaseMetaData.functionParameterOut)); [javac]^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:157: cannot find symbol [javac] symbol : method getFunctionParameters(,,java.lang.String,) [javac] location: interface java.sql.DatabaseMetaData [javac] dumpRS(met.getFunctionParameters(null,null,"DUMMY%",null)); [javac] ^ [javac] /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java:160: cannot find symbol [javac] symbol : method getFunctionParameters(,,java.lang.String,java.lang.String) [javac] location: interface java.sql.DatabaseMetaData [javac] dumpRS(met.getFunctionParameters(null,null,"DUMMY%","")); [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 9 errors BUILD FAILED /export/home/dv136566/derby/patch/trunk/build.xml:336: The following error occurred while executing this line: /export/home/dv136566/derby/patch/trunk/java/testing/build.xml:75: The following error occurred while executing this line: /export/home/dv136566/derby/patch/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/build.xml:64: Compile failed; see the compiler error output for details.
[jira] Updated: (DERBY-744) Problem setting sanity state to false by using 'ant -Dsane=false'
[ http://issues.apache.org/jira/browse/DERBY-744?page=all ] Andrew McIntyre updated DERBY-744: -- Attachment: derby-744-v1.diff Attaching patch for this issue. > Problem setting sanity state to false by using 'ant -Dsane=false' > - > > Key: DERBY-744 > URL: http://issues.apache.org/jira/browse/DERBY-744 > Project: Derby > Issue Type: Bug > Components: Build tools >Affects Versions: 10.2.1.0, 10.1.2.1, 10.1.3.0, 10.1.2.2 >Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre >Priority: Minor > Fix For: 10.2.2.0 > > Attachments: derby-744-v1.diff > > > Problem report from Kathey Marsden: > There seems to be some sort of problem with the sanity state. > After ant clobber, rm -rf jars, rm -rf snapshot no apparent problematic > files, ant -Dsane=false snapshot seemed to sometimes build the jars to > the sane jar directory and yield the following error. > > [delete] Deleting directory D:\svn\opensource\10.1\javadoc\sourcedir >[mkdir] Created dir: D:\svn\opensource\10.1\snapshot > BUILD FAILED > D:\svn\opensource\10.1\build.xml:1287: > D:\svn\opensource\10.1\jars\insane not found. > A reliable workaround was to run > ant insane > before ant -Dsane=false snapshot. -- 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: Re: LineNumber table in class files and sane=false strangeness
On 8/21/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Doing this provides a consistent build (thanks Andrew): ant clobber ant insanse ant all Looking at the previous verbose output for a full build shows all the compiles had just -g, not -g:none. Maybe just setting the ant property 'sane=false' is no longer enough, one one needs to run 'ant insane'? It does seem my codeline was in a half insane, half sane mode. This definitely sounds like DERBY-744 if running 'ant insane' fixes the problem. I was having a problem reproducing it when running with -Dsane=false, but putting it in my ~/ant.properties reproduces the problem. And, I found the solution, a check for the property sane was using the value of the property, instead of checking the sane property itself. I'll attach a patch to DERBY-744. Dan, please let me know if this solves the problem without running 'ant insane' first. andrew
[jira] Commented: (DERBY-1674) Investigate reducing the number of classes & methods in DataDictionary used to represent system tables
[ http://issues.apache.org/jira/browse/DERBY-1674?page=comments#action_12429571 ] Daniel John Debrunner commented on DERBY-1674: -- Correct stats for an insane build: Revision: 433398 Number of RowFactory classes 21 Size of RowFactory classes 126750 org/apache/derby/iapi/sql/dictionary Number of Dictionary api classes 46 Size of Dictionary api classes 159707 org/apache/derby/impl/sql/catalog Number of Catalog impl classes 37 Size of Catalog impl classes 268842 > Investigate reducing the number of classes & methods in DataDictionary used > to represent system tables > --- > > Key: DERBY-1674 > URL: http://issues.apache.org/jira/browse/DERBY-1674 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner >Priority: Minor > > Currently two classes exists for each system table, one to represent the > table (e.g.SYSTABLESRowFactory) , one to represent a row (e.g. > TableDescriptor) > Look at having a single row factory (CatalogRowFactory) and using > polymorphism (method overloading) on the descriptor objects to perform the > work > that is done today (e.g. converting a descriptor to and from a Row object). > In addition the DataDictionary has a specific method to drop each type of > unique descriptor (e.g. dropSPSDescriptor, dropAliasDescriptor) > Would it be possible to have a single > dropDescriptor(UniqueSQLObjectDescriptor) method and again use polymorphism > on the descriptors. -- 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: LineNumber table in class files and sane=false strangeness
Daniel John Debrunner wrote: > Daniel John Debrunner wrote: > > > >>If I remove PermissionsCatalogRowFactory.class and recompile just using >>ant from the top level then it reverts to 2116 bytes in the first codeline. >> >>Doing a ant clobber followed by an ant -verbose all in the first >>codeline reveals this as the only entry for that class. >> >>[javac] >>org\apache\derby\impl\sql\catalog\PermissionsCatalogRowFactory.java >>omitted as >>org/apache/derby/impl/sql/catalog/PermissionsCatalogRowFactory.class is >>up to date. >> >>So I assume something else is compiling it indirectly with a different >>-g flag, that doesn't match my sane=false setting, any ideas? > > > Doing this provides a consistent build (thanks Andrew): > > ant clobber > ant insanse > ant all That was wrong on two counts. Start again. :-) ant clobber ant insane ant builds correctly ant clobber ant insane ant all builds incorrectly (with line number tables). I wonder if the 'demo' target is getting built before the 'buildsource' target and indirectly building most of the engine. Dependency ordering seems like the kind of thing that could be dependent on a hashtable in ant, thus leading to different behaviour across codelines. Trying now with demo depending on buildsource Dan.
Re: LineNumber table in class files and sane=false strangeness
Daniel John Debrunner wrote: > If I remove PermissionsCatalogRowFactory.class and recompile just using > ant from the top level then it reverts to 2116 bytes in the first codeline. > > Doing a ant clobber followed by an ant -verbose all in the first > codeline reveals this as the only entry for that class. > > [javac] > org\apache\derby\impl\sql\catalog\PermissionsCatalogRowFactory.java > omitted as > org/apache/derby/impl/sql/catalog/PermissionsCatalogRowFactory.class is > up to date. > > So I assume something else is compiling it indirectly with a different > -g flag, that doesn't match my sane=false setting, any ideas? Doing this provides a consistent build (thanks Andrew): ant clobber ant insanse ant all Looking at the previous verbose output for a full build shows all the compiles had just -g, not -g:none. Maybe just setting the ant property 'sane=false' is no longer enough, one one needs to run 'ant insane'? It does seem my codeline was in a half insane, half sane mode. Dan.
[jira] Commented: (DERBY-1655) Document XML functionality for 10.2
[ http://issues.apache.org/jira/browse/DERBY-1655?page=comments#action_12429569 ] A B commented on DERBY-1655: > I think it might be better to just have SQL/XML, except perhaps in a concept > topic, like > cdevstandardsxml "XML data type and operators" Where most of the overview and > general information should be. Sounds good to me... > Document XML functionality for 10.2 > --- > > Key: DERBY-1655 > URL: http://issues.apache.org/jira/browse/DERBY-1655 > Project: Derby > Issue Type: Task > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: A B > Assigned To: Laura Stewart > Fix For: 10.2.1.0 > > Attachments: ctoolsimport27052.html, derby1655_devguide.diff, > derby1655_devguide_html.zip, derby1655_ref.diff, derby1655_ref_html.zip, > derby1655_tools_html.diff, derby1655_tuning.diff, derby1655_tuning_html.zip, > DerbyXMLDoc_v1.html, DerbyXMLDoc_v2.html > > > DERBY-334 and DERBY-688 have added an XML datatype and four XML operators to > Derby. These are all going to be exposed to the user for general use as part > of the 10.2. release, so the datatype and operators need to be documented > 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-1655) Document XML functionality for 10.2
[ http://issues.apache.org/jira/browse/DERBY-1655?page=comments#action_12429567 ] Laura Stewart commented on DERBY-1655: -- In the updated DerbyXMLDoc_v2.html file, there are references to SQL/XML[2006]. Do we really want to qualify the year? I think it might be better to just have SQL/XML, except perhaps in a concept topic, like cdevstandardsxml "XML data type and operators" Where most of the overview and general information should be. > Document XML functionality for 10.2 > --- > > Key: DERBY-1655 > URL: http://issues.apache.org/jira/browse/DERBY-1655 > Project: Derby > Issue Type: Task > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: A B > Assigned To: Laura Stewart > Fix For: 10.2.1.0 > > Attachments: ctoolsimport27052.html, derby1655_devguide.diff, > derby1655_devguide_html.zip, derby1655_ref.diff, derby1655_ref_html.zip, > derby1655_tools_html.diff, derby1655_tuning.diff, derby1655_tuning_html.zip, > DerbyXMLDoc_v1.html, DerbyXMLDoc_v2.html > > > DERBY-334 and DERBY-688 have added an XML datatype and four XML operators to > Derby. These are all going to be exposed to the user for general use as part > of the 10.2. release, so the datatype and operators need to be documented > 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-1731) Add warning to Derby docs that the JDBC 4.0 support is based upon the proposed final draft of JSR 221 and might change in subsequent releases.
[ http://issues.apache.org/jira/browse/DERBY-1731?page=comments#action_12429566 ] Laura Stewart commented on DERBY-1731: -- Shouldn't this go into the Release Notes? I believe that is what Dan has marked on the issue. > Add warning to Derby docs that the JDBC 4.0 support is based upon the > proposed final draft of JSR 221 and might change in subsequent releases. > --- > > Key: DERBY-1731 > URL: http://issues.apache.org/jira/browse/DERBY-1731 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.0, 10.2.2.0 >Reporter: Daniel John Debrunner > Fix For: 10.2.1.0, 10.2.2.0 > > > While JDBC 4.0 does not require any warning statement (see DEBRY-1639) it > would be good for Derby to have such a statement. > I think we want to freedom to match JDBC 4.0 final spec in a future 10.2 > release, a warning would help this, including stating that > applications written to JDBC 4.0 might need to be modified and re-compile to > work successfully. -- 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-1405) New javadoc needs to be wired into documentation
[ http://issues.apache.org/jira/browse/DERBY-1405?page=comments#action_12429562 ] Daniel John Debrunner commented on DERBY-1405: -- Minor comment on page, I think one should use JDBC 2.1/JDBC 3.0 JDBC 4.0 rather than JDBC2/JDBC3 JDBC4 > New javadoc needs to be wired into documentation > > > Key: DERBY-1405 > URL: http://issues.apache.org/jira/browse/DERBY-1405 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: Rick Hillegas > Assigned To: Andrew McIntyre > Fix For: 10.2.1.0 > > Attachments: derby-1405-v1.diff, derby-1405-v2.diff, index.html > > > The javadoc has been split into JDBC3 and JDBC4 specific version (see > DERBY-1079). Andrew suggested that a top level web page pointing at this > javadoc needs to be wired into the released documentation. -- 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
LineNumber table in class files and sane=false strangeness
I'm trying to figure out when one of my derby codelines compiles with LineNumber tables and one without. They have identical ant.properties files that I use to build, with sane=false. Compling an individual file shows the -g:none flag being used in both cases, but I end up with class files of vastly different sizes from an: ant clobber ant all In the bigger classes I can dump the raw format and see the line number table is in there, in the smaller ones it seems to be missing. E.g. First codeline 2746 PermissionsCatalogRowFactory.class Second codeline 2116 PermissionsCatalogRowFactory.class If I remove PermissionsCatalogRowFactory.class and recompile just using ant from the top level then it reverts to 2116 bytes in the first codeline. Doing a ant clobber followed by an ant -verbose all in the first codeline reveals this as the only entry for that class. [javac] org\apache\derby\impl\sql\catalog\PermissionsCatalogRowFactory.java omitted as org/apache/derby/impl/sql/catalog/PermissionsCatalogRowFactory.class is up to date. So I assume something else is compiling it indirectly with a different -g flag, that doesn't match my sane=false setting, any ideas? Thanks, Dan.
[jira] Commented: (DERBY-1405) New javadoc needs to be wired into documentation
[ http://issues.apache.org/jira/browse/DERBY-1405?page=comments#action_12429559 ] Rick Hillegas commented on DERBY-1405: -- I think it looks great. It's brief and it points at all the important resources (including the demos). In addition, I like the division into sections for newbies and veterans. > New javadoc needs to be wired into documentation > > > Key: DERBY-1405 > URL: http://issues.apache.org/jira/browse/DERBY-1405 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: Rick Hillegas > Assigned To: Andrew McIntyre > Fix For: 10.2.1.0 > > Attachments: derby-1405-v1.diff, derby-1405-v2.diff, index.html > > > The javadoc has been split into JDBC3 and JDBC4 specific version (see > DERBY-1079). Andrew suggested that a top level web page pointing at this > javadoc needs to be wired into the released documentation. -- 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-1437) Add new LRU Cache Manager
[ http://issues.apache.org/jira/browse/DERBY-1437?page=all ] Gokul Soundararajan updated DERBY-1437: --- Attachment: clockpro-aug-19-2006.zip ClockFactory.diff This is the code for ClockProCache. Again the only change to existing code is ClockFactory. > Add new LRU Cache Manager > - > > Key: DERBY-1437 > URL: http://issues.apache.org/jira/browse/DERBY-1437 > Project: Derby > Issue Type: Improvement > Components: Services >Reporter: Gokul Soundararajan > Assigned To: Gokul Soundararajan > Attachments: ClockFactory.diff, clockpro-aug-19-2006.zip, > pluggable-aug-19-2006.zip > > > In databases, caching plays an important role in performance. To obtain high > performance, we need to cache pages from disk in memory to reduce access > time. The problem stated is that the existing replacement algorithm performs > poorly so we need to research new algorithms for page replacement and > implement it in Apache Derby. The benefit of a better algorithm is improved > performance. > In this project, I first have to look at existing work to quantify the > different replacement algorithms used in databases. I have run simulation > experiments on several cache replacement algorithms from FIFO, Clock, > Clock-Pro, TwoQueue, CAR, and CART. CAR/CART are patented by IBM so we cannot > implement them in Derby. Two Queue has a large synchronization overhead (seen > by Postgres community). Clock-Pro performs well and is being implemented in > Linux. Oystein and I have agreed to implement Clock-Pro inside Derby. See the > wiki for more details and simulation results: > http://wiki.apache.org/db-derby/DerbyLruCacheManager > I will implement it in Derby. In addition, I will implement unit tests. > Finally, I will perform experiments showing the benefit of the new algorithm > over the existing algorithm. -- 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-1437) Add new LRU Cache Manager
[ http://issues.apache.org/jira/browse/DERBY-1437?page=all ] Gokul Soundararajan updated DERBY-1437: --- Attachment: pluggable-aug-19-2006.zip These files are needed for the PluggableCache architecture. The original Clock isn't modified. I just created a PluggableCache class. Each replacement policy is in its own class. Just place them in java/engine/org/apache/derby/impl/services/cache/. I have attached the ClockFactory diff to enable my caches to run. > Add new LRU Cache Manager > - > > Key: DERBY-1437 > URL: http://issues.apache.org/jira/browse/DERBY-1437 > Project: Derby > Issue Type: Improvement > Components: Services >Reporter: Gokul Soundararajan > Assigned To: Gokul Soundararajan > Attachments: pluggable-aug-19-2006.zip > > > In databases, caching plays an important role in performance. To obtain high > performance, we need to cache pages from disk in memory to reduce access > time. The problem stated is that the existing replacement algorithm performs > poorly so we need to research new algorithms for page replacement and > implement it in Apache Derby. The benefit of a better algorithm is improved > performance. > In this project, I first have to look at existing work to quantify the > different replacement algorithms used in databases. I have run simulation > experiments on several cache replacement algorithms from FIFO, Clock, > Clock-Pro, TwoQueue, CAR, and CART. CAR/CART are patented by IBM so we cannot > implement them in Derby. Two Queue has a large synchronization overhead (seen > by Postgres community). Clock-Pro performs well and is being implemented in > Linux. Oystein and I have agreed to implement Clock-Pro inside Derby. See the > wiki for more details and simulation results: > http://wiki.apache.org/db-derby/DerbyLruCacheManager > I will implement it in Derby. In addition, I will implement unit tests. > Finally, I will perform experiments showing the benefit of the new algorithm > over the existing algorithm. -- 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-1731) Add warning to Derby docs that the JDBC 4.0 support is based upon the proposed final draft of JSR 221 and might change in subsequent releases.
[ http://issues.apache.org/jira/browse/DERBY-1731?page=comments#action_12429555 ] Rick Hillegas commented on DERBY-1731: -- Where should we put this disclaimer? We could put in in the Reference Guide in the "JDBC Reference" section. > Add warning to Derby docs that the JDBC 4.0 support is based upon the > proposed final draft of JSR 221 and might change in subsequent releases. > --- > > Key: DERBY-1731 > URL: http://issues.apache.org/jira/browse/DERBY-1731 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.0, 10.2.2.0 >Reporter: Daniel John Debrunner > Fix For: 10.2.1.0, 10.2.2.0 > > > While JDBC 4.0 does not require any warning statement (see DEBRY-1639) it > would be good for Derby to have such a statement. > I think we want to freedom to match JDBC 4.0 final spec in a future 10.2 > release, a warning would help this, including stating that > applications written to JDBC 4.0 might need to be modified and re-compile to > work successfully. -- 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-1405) New javadoc needs to be wired into documentation
[ http://issues.apache.org/jira/browse/DERBY-1405?page=comments#action_12429552 ] Andrew McIntyre commented on DERBY-1405: Sure, although the new index.html contains a link to the logo image which isn't included with the documentation yet. I'm working on that as a part of DERBY-935, and should have a patch for that shortly. Any comments on the content of the new index.html? > New javadoc needs to be wired into documentation > > > Key: DERBY-1405 > URL: http://issues.apache.org/jira/browse/DERBY-1405 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: Rick Hillegas > Assigned To: Andrew McIntyre > Fix For: 10.2.1.0 > > Attachments: derby-1405-v1.diff, derby-1405-v2.diff, index.html > > > The javadoc has been split into JDBC3 and JDBC4 specific version (see > DERBY-1079). Andrew suggested that a top level web page pointing at this > javadoc needs to be wired into the released documentation. -- 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-1405) New javadoc needs to be wired into documentation
[ http://issues.apache.org/jira/browse/DERBY-1405?page=comments#action_12429550 ] Rick Hillegas commented on DERBY-1405: -- Just wondering if this patch is ready for commit? > New javadoc needs to be wired into documentation > > > Key: DERBY-1405 > URL: http://issues.apache.org/jira/browse/DERBY-1405 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: Rick Hillegas > Assigned To: Andrew McIntyre > Fix For: 10.2.1.0 > > Attachments: derby-1405-v1.diff, derby-1405-v2.diff, index.html > > > The javadoc has been split into JDBC3 and JDBC4 specific version (see > DERBY-1079). Andrew suggested that a top level web page pointing at this > javadoc needs to be wired into the released documentation. -- 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-1742) SYSTEMALIAS column of type BOOLEAN in SYS.SYSALIASES is created with the incorrect maximun length of 0
SYSTEMALIAS column of type BOOLEAN in SYS.SYSALIASES is created with the incorrect maximun length of 0 -- Key: DERBY-1742 URL: http://issues.apache.org/jira/browse/DERBY-1742 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0 Reporter: Daniel John Debrunner Priority: Trivial Boolean type's correct maximum width is 1. Seen by the COLUMN_SIZE column from DatabaseMetaData.getColumns returning 0 instead of 1. Caused by passing a 0 instead of a 1 in SYSAliasesRowFactory, will be fixed by DERBY-1734, which stops code like this passing in information that is redundant (and hence a chance for it to be wrong). Don't believe ir has any affect on the runtime behaviour of the system, adding this issue to investigate if an upgrade fix is required or just leave it at the wrong value for old databases. -- 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-688) Enhancements to XML functionality to move toward XPath/XQuery support...
A B (JIRA) wrote: So this patch, d688_phase6_v1.patch, is ready for commit. Thanks Army! I intend to review and commit this change. If anyone else is reviewing it, please let me know. thanks, bryan
[jira] Updated: (DERBY-1741) Remove the references for cloudscape and cloudcape
[ http://issues.apache.org/jira/browse/DERBY-1741?page=all ]
Manjula Kutty updated DERBY-1741:
-
Description:
Please remove the references to cloudscape.LOG and cloudcape.LOG from the
message files. Following are the list of files I got after doing a search
tools\org\apache\derby\loc\toolsmessages_de_DE.properties(172):
IJ_01SeeClouLog={0} : {1} (siehe cloudscape.LOG)
tools\org\apache\derby\loc\toolsmessages_es.properties(175):
IJ_01SeeClouLog={0} : {1} (consulte cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_fr.properties(172):
IJ_01SeeClouLog={0} : {1} (voir cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_it.properties(172):
IJ_01SeeClouLog={0} : {1} (consultare cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_ja_JP.properties(172):
IJ_01SeeClouLog={0} : {1} (cloudcape.LOG \u3092\u53c2\u7167)
tools\org\apache\derby\loc\toolsmessages_ko_KR.properties(172):
IJ_01SeeClouLog={0} : {1} (cloudcape.LOG \ucc38\uc870)
tools\org\apache\derby\loc\toolsmessages_zh_CN.properties(172):
IJ_01SeeClouLog={0} : {1}\uff08\u8bf7\u53c2\u9605 cloudcape.LOG\uff09
tools\org\apache\derby\loc\toolsmessages_zh_TW.properties(172):
IJ_01SeeClouLog={0}\uff1a{1}\uff08\u8acb\u53c3\u95b1 cloudcape.LOG\uff09
was:
Please remove the references to cloudscape.LOG and cloudcape.LOg from the
message files. Following are the list of files I got after doing a seach
tools\org\apache\derby\loc\toolsmessages_de_DE.properties(172):
IJ_01SeeClouLog={0} : {1} (siehe cloudscape.LOG)
tools\org\apache\derby\loc\toolsmessages_es.properties(175):
IJ_01SeeClouLog={0} : {1} (consulte cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_fr.properties(172):
IJ_01SeeClouLog={0} : {1} (voir cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_it.properties(172):
IJ_01SeeClouLog={0} : {1} (consultare cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_ja_JP.properties(172):
IJ_01SeeClouLog={0} : {1} (cloudcape.LOG \u3092\u53c2\u7167)
tools\org\apache\derby\loc\toolsmessages_ko_KR.properties(172):
IJ_01SeeClouLog={0} : {1} (cloudcape.LOG \ucc38\uc870)
tools\org\apache\derby\loc\toolsmessages_zh_CN.properties(172):
IJ_01SeeClouLog={0} : {1}\uff08\u8bf7\u53c2\u9605 cloudcape.LOG\uff09
tools\org\apache\derby\loc\toolsmessages_zh_TW.properties(172):
IJ_01SeeClouLog={0}\uff1a{1}\uff08\u8acb\u53c3\u95b1 cloudcape.LOG\uff09
> Remove the references for cloudscape and cloudcape
> --
>
> Key: DERBY-1741
> URL: http://issues.apache.org/jira/browse/DERBY-1741
> Project: Derby
> Issue Type: Bug
>Reporter: Manjula Kutty
>Priority: Minor
> Fix For: 10.2.1.0
>
>
> Please remove the references to cloudscape.LOG and cloudcape.LOG from the
> message files. Following are the list of files I got after doing a search
> tools\org\apache\derby\loc\toolsmessages_de_DE.properties(172):
> IJ_01SeeClouLog={0} : {1} (siehe cloudscape.LOG)
> tools\org\apache\derby\loc\toolsmessages_es.properties(175):
> IJ_01SeeClouLog={0} : {1} (consulte cloudcape.LOG)
> tools\org\apache\derby\loc\toolsmessages_fr.properties(172):
> IJ_01SeeClouLog={0} : {1} (voir cloudcape.LOG)
> tools\org\apache\derby\loc\toolsmessages_it.properties(172):
> IJ_01SeeClouLog={0} : {1} (consultare cloudcape.LOG)
> tools\org\apache\derby\loc\toolsmessages_ja_JP.properties(172):
> IJ_01SeeClouLog={0} : {1} (cloudcape.LOG \u3092\u53c2\u7167)
> tools\org\apache\derby\loc\toolsmessages_ko_KR.properties(172):
> IJ_01SeeClouLog={0} : {1} (cloudcape.LOG \ucc38\uc870)
> tools\org\apache\derby\loc\toolsmessages_zh_CN.properties(172):
> IJ_01SeeClouLog={0} : {1}\uff08\u8bf7\u53c2\u9605 cloudcape.LOG\uff09
> tools\org\apache\derby\loc\toolsmessages_zh_TW.properties(172):
> IJ_01SeeClouLog={0}\uff1a{1}\uff08\u8acb\u53c3\u95b1 cloudcape.LOG\uff09
--
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-1741) Remove the references for cloudscape and cloudcape
Remove the references for cloudscape and cloudcape
--
Key: DERBY-1741
URL: http://issues.apache.org/jira/browse/DERBY-1741
Project: Derby
Issue Type: Bug
Reporter: Manjula Kutty
Priority: Minor
Fix For: 10.2.1.0
Please remove the references to cloudscape.LOG and cloudcape.LOg from the
message files. Following are the list of files I got after doing a seach
tools\org\apache\derby\loc\toolsmessages_de_DE.properties(172):
IJ_01SeeClouLog={0} : {1} (siehe cloudscape.LOG)
tools\org\apache\derby\loc\toolsmessages_es.properties(175):
IJ_01SeeClouLog={0} : {1} (consulte cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_fr.properties(172):
IJ_01SeeClouLog={0} : {1} (voir cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_it.properties(172):
IJ_01SeeClouLog={0} : {1} (consultare cloudcape.LOG)
tools\org\apache\derby\loc\toolsmessages_ja_JP.properties(172):
IJ_01SeeClouLog={0} : {1} (cloudcape.LOG \u3092\u53c2\u7167)
tools\org\apache\derby\loc\toolsmessages_ko_KR.properties(172):
IJ_01SeeClouLog={0} : {1} (cloudcape.LOG \ucc38\uc870)
tools\org\apache\derby\loc\toolsmessages_zh_CN.properties(172):
IJ_01SeeClouLog={0} : {1}\uff08\u8bf7\u53c2\u9605 cloudcape.LOG\uff09
tools\org\apache\derby\loc\toolsmessages_zh_TW.properties(172):
IJ_01SeeClouLog={0}\uff1a{1}\uff08\u8acb\u53c3\u95b1 cloudcape.LOG\uff09
--
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: Regarding getting old snapshots of 10.2 ( was Re: 10.1.2.4 snapshot posted)
Andrew McIntyre wrote: or use viewvc to get a download link without having to check out the site tree. That helps. Thanks Andrew and Rick. Sunitha.
Regression Test Failure! - TinderBox_Derby 433317 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 433317/2006-08-21 20:32:59 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1672671 2 155.29% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-433317.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/433317.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/433317.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: Regarding getting old snapshots of 10.2 ( was Re: 10.1.2.4 snapshot posted)
Hi Sunitha, The 10.2.0.4 alpha snapshot is still visible from the downloads page. You can get ahold of an older snapshot than that, although it's not pretty. The snapshots hang off the Derby website and so are checked into the Derby website repository. You need to create a subversion client against the Derby website then use subversion to roll that client back in time to whenever your desired snapshot was current. Hope this helps, -Rick Sunitha Kambhampati wrote: Andrew McIntyre wrote: On 5/10/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: However, I think when a snapshot is posted we should leave the older snapshots on the download page. Makes it much easier for people to demonstrate a regression if they can easily show it's in the latest snapshot but not the previous snapshot. Maybe the snapshots should only be removed once an official release is made on the branch for the snapshots. Thoughts? I agree with Dan about leaving old snapshots on the download page. For e.g: Currently- I found that the largeDataTests suite was taking more time to run with the 10.2.1.0 beta jars than what I had observed a couple months back and I was hoping to run my test with the old snapshot jars and now I cant get to them atleast from the download page. Just want to note that you can still get the older ones from svn if you need them, also. Are the snapshot jars stored in svn someplace ? Where can I get them from. It would be great if you can point me to the link. Thanks much, Sunitha.
Re: Regarding getting old snapshots of 10.2 ( was Re: 10.1.2.4 snapshot posted)
On 8/21/06, Sunitha Kambhampati <[EMAIL PROTECTED]> wrote: Are the snapshot jars stored in svn someplace ? Where can I get them from. It would be great if you can point me to the link. The jars are stored in svn with the website, in the site tree. You can run svn log on build/site/binaries in the site tree to determine the revisions where snapshots were added or changed: svn log https://svn.apache.org/repos/asf/db/derby/site/ trunk/build/site/binaries/ > binaries.log You could either then go back to that revision if you have a local copy of the website, or use viewvc to get a download link without having to check out the site tree. As an example, from the log you can see that 10.2.0.3 was added at revision 413060. Going to the build/site/binaries directory in the site tree with viewvc, and setting the directory revision to 413060, you can see the 10.2.0.3 snapshot: http://svn.apache.org/viewvc/db/derby/site/trunk/build/site/binaries/?pathrev=413060 Clicking on db-derby-snapshot-10.2.0.3-412239.zip takes us to this page: http://svn.apache.org/viewvc/db/derby/site/trunk/build/site/binaries/db-derby-snapshot-10.2.0.3-412239.zip?view=log&pathrev=413060 which contains a download link for 10.2.0.3. andrew
Re: drop column functionality
Deepa Remesh wrote: > On 8/21/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote: > >> >> > 3. The version from trunk does not appear able to read databases >> created >> > with the 10.1.3.1 release. Has the database file syntax changed? >> >> I'm hoping one of the other developers can help with this question. >> I think that this is on purpose, to avoid accidentally mixing releases >> that may differ in major ways, but I think there is a configuration >> flag that you can set that will authorize the trunk code to open and >> read a previous-release database. >> >> Can anybody help us out here? How can Tim use some of his 10.1 databases >> in experimenting with a patched release built from the trunk? >> > > Setting "derby.database.allowPreReleaseUpgrade" system property to > true will allow pre-release code (like trunk code) to read databases > from previous release. Note that this property is only to be used for > testing. Please take a look at these links for additional info: > http://www.nabble.com/Re%3A-Soft-Upgrade-question-p3441560.html > http://wiki.apache.org/db-derby/UpgradingTen and be warned since the trunk has only just been bumped to reflect version 10.3 the corresponding upgrade code has *not* been updated. This may mean the upgrade code is non-functional at this point in time on the trunk. Dan.
[jira] Updated: (DERBY-1740) Change error message to indicate encryptionkey length to be atleast 16 characters instead of 8 characters
[ http://issues.apache.org/jira/browse/DERBY-1740?page=all ] Rajesh Kartha updated DERBY-1740: - Fix Version/s: 10.2.1.0 Affects Version/s: 10.0.2.0 update fix versions > Change error message to indicate encryptionkey length to be atleast 16 > characters instead of 8 characters > - > > Key: DERBY-1740 > URL: http://issues.apache.org/jira/browse/DERBY-1740 > Project: Derby > Issue Type: Bug >Affects Versions: 10.0.2.0 > Environment: Any >Reporter: Rajesh Kartha >Priority: Minor > Fix For: 10.2.1.0 > > > While attempting to create a encrypted database with even key length of 14 > characters, it fails with the error message indicating the key length should > be atleast 8 characters. > -- > -- Attempt to encrypt using key of lenght 14 > -- > ij> connect > 'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=11223344556677'; > ERROR XJ041: Failed to create database 'adb', see the next exception for > details. > ERROR XBM01: Startup failed due to an exception. See next exception for > details. > ERROR XBCX2: Initializing cipher with a boot password that is too short. The > password must be at least 8 characters long. > -- > --Requires 16 characters for the encryptionKey > -- > ij> connect > 'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=1122334455667788'; > ij> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regarding getting old snapshots of 10.2 ( was Re: 10.1.2.4 snapshot posted)
Andrew McIntyre wrote: On 5/10/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: However, I think when a snapshot is posted we should leave the older snapshots on the download page. Makes it much easier for people to demonstrate a regression if they can easily show it's in the latest snapshot but not the previous snapshot. Maybe the snapshots should only be removed once an official release is made on the branch for the snapshots. Thoughts? I agree with Dan about leaving old snapshots on the download page. For e.g: Currently- I found that the largeDataTests suite was taking more time to run with the 10.2.1.0 beta jars than what I had observed a couple months back and I was hoping to run my test with the old snapshot jars and now I cant get to them atleast from the download page. Just want to note that you can still get the older ones from svn if you need them, also. Are the snapshot jars stored in svn someplace ? Where can I get them from. It would be great if you can point me to the link. Thanks much, Sunitha.
[jira] Created: (DERBY-1740) Change error message to indicate encryptionkey length to be atleast 16 characters instead of 8 characters
Change error message to indicate encryptionkey length to be atleast 16 characters instead of 8 characters - Key: DERBY-1740 URL: http://issues.apache.org/jira/browse/DERBY-1740 Project: Derby Issue Type: Bug Environment: Any Reporter: Rajesh Kartha Priority: Minor While attempting to create a encrypted database with even key length of 14 characters, it fails with the error message indicating the key length should be atleast 8 characters. -- -- Attempt to encrypt using key of lenght 14 -- ij> connect 'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=11223344556677'; ERROR XJ041: Failed to create database 'adb', see the next exception for details. ERROR XBM01: Startup failed due to an exception. See next exception for details. ERROR XBCX2: Initializing cipher with a boot password that is too short. The password must be at least 8 characters long. -- --Requires 16 characters for the encryptionKey -- ij> connect 'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=1122334455667788'; ij> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ] A B updated DERBY-688: -- Derby Info: [Patch Available] > Enhancements to XML functionality to move toward XPath/XQuery support... > > > Key: DERBY-688 > URL: http://issues.apache.org/jira/browse/DERBY-688 > Project: Derby > Issue Type: Improvement > Components: JDBC, SQL >Reporter: A B > Assigned To: A B >Priority: Minor > Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, > d688_phase1_v2.patch, d688_phase1_v3.patch, d688_phase2_v1_code.patch, > d688_phase2_v1_tests.patch, d688_phase2_v2_tests.patch, > d688_phase2_v3_tests.patch, d688_phase3_v1_code.patch, > d688_phase3_v1_tests.patch, d688_phase4_v1.patch, d688_phase4_v2.patch, > d688_phase5_v1.patch, d688_phase6_v1.patch, derbyXMLSpec.html > > > As of DERBY-334, Derby has some very basic support for XML that consists of > an XML datatype and three operators (XMLPARSE, XMLSERIALIZE, and XMLEXISTS). > I would like to enhance this existing functionality and, by doing so, help to > move Derby incrementally toward a more usable and more complete XPath/XQuery > solution (with emphasis on "incrementally"). > I have attached to this issue a document describing the particular changes > that I am looking to make. At a high level, they consist of: > 1) Making it easier to use the XML operators and datatype from within JDBC > (ex. by implicit parsing/serialization of XML values). > 2) Adding a new operator, XMLQUERY, to allow a user to retrieve the results > of an XPath expression (instead of just determining whether or not the > expression evaluates to an empty sequence, which is what XMLEXISTS does). > 3) Making changes to the existing operators to line them up with the SQL/XML > 2005 specification, and also to take steps toward my eventual hope of having > support for XQuery (as opposed to just XPath) in Derby. > If anyone has time and interest enough to look at the document and provide > feedback, that'd be great... -- 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-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ] A B updated DERBY-688: -- Attachment: d688_phase6_v1.patch Attaching a phase 6 patch, d688_phase6_v1.patch, that changes the SQLSTATEs for XML errors to match the SQL/XML specification where possible, and that moves the Derby-specific XML sql states to a compile-time range (42Z70 - 42Z7Z) instead of an execution-time range (X0Xxx). I applied the patch, did an ant clobber followed by an ant all, then ran xmlSuite with ibm142 and all tests passed (Windows). So this patch, d688_phase6_v1.patch, is ready for commit. > Enhancements to XML functionality to move toward XPath/XQuery support... > > > Key: DERBY-688 > URL: http://issues.apache.org/jira/browse/DERBY-688 > Project: Derby > Issue Type: Improvement > Components: JDBC, SQL >Reporter: A B > Assigned To: A B >Priority: Minor > Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, > d688_phase1_v2.patch, d688_phase1_v3.patch, d688_phase2_v1_code.patch, > d688_phase2_v1_tests.patch, d688_phase2_v2_tests.patch, > d688_phase2_v3_tests.patch, d688_phase3_v1_code.patch, > d688_phase3_v1_tests.patch, d688_phase4_v1.patch, d688_phase4_v2.patch, > d688_phase5_v1.patch, d688_phase6_v1.patch, derbyXMLSpec.html > > > As of DERBY-334, Derby has some very basic support for XML that consists of > an XML datatype and three operators (XMLPARSE, XMLSERIALIZE, and XMLEXISTS). > I would like to enhance this existing functionality and, by doing so, help to > move Derby incrementally toward a more usable and more complete XPath/XQuery > solution (with emphasis on "incrementally"). > I have attached to this issue a document describing the particular changes > that I am looking to make. At a high level, they consist of: > 1) Making it easier to use the XML operators and datatype from within JDBC > (ex. by implicit parsing/serialization of XML values). > 2) Adding a new operator, XMLQUERY, to allow a user to retrieve the results > of an XPath expression (instead of just determining whether or not the > expression evaluates to an empty sequence, which is what XMLEXISTS does). > 3) Making changes to the existing operators to line them up with the SQL/XML > 2005 specification, and also to take steps toward my eventual hope of having > support for XQuery (as opposed to just XPath) in Derby. > If anyone has time and interest enough to look at the document and provide > feedback, that'd be great... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4
[ http://issues.apache.org/jira/browse/DERBY-1633?page=comments#action_12429520 ] A B commented on DERBY-1633: I applied the _v3 patches and ran derbyall on Red Hat Linux with ibm142 against sane jars with no new failures. So as mentioned in my previous comment, the d1633_v3_code.patch and d1633_v3_tests.patch patches are ready for review and commit. > Regression: The fields of views are not being calculated properly since > 10.1.2.4 > > > Key: DERBY-1633 > URL: http://issues.apache.org/jira/browse/DERBY-1633 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.1.3.0, 10.1.3.1 > Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory >Reporter: Prasenjit Sarkar > Assigned To: A B > Fix For: 10.2.1.0 > > Attachments: d1633_repro.sql, d1633_v1_reviewOnly.patch, > d1633_v2.patch, d1633_v3_code.patch, d1633_v3_tests.patch, > DERBY-1633_v1.html, DERBY-1633_v2.html, DERBY-1633_v3.html > > > Database can be assumed to be same as in Derby - 1205 Jira issue > SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT > WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID > This works fine in 10.1.2.1 but fails thereafter complaining that Comparison > between INTEGER and CHAR is not supported > for some reason, it thinks one of the PORT_ID columns is a character, when in > reality both are integers. > SELECT DISTINCT > ZONE.ZONE_ID ZONE_ID, >PORT2ZONE.ZONE_MEMBER_ID > FROM >T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE > PORT2ZONE on >ZONE.ZONE_ID = PORT2ZONE.ZONE_ID , T_RES_FABRIC > FABRIC > In this query, it is complaining that one of the columns is a VARCHAR and > cannot be compared to INTEGER, when clearly this is not the case... > Same issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Mustang license (was Re: spec license updated, looks good ...)
I want to keep the community informed on where this issue stands right now. The short story is that the lawyers are still working on some solution which will allow us to build our JDBC4 drivers even though Java SE 6 is still in beta. The lawyers know that we want to build a release candidate at the end of this week. In the meantime, I have successfully built Derby's JDBC4 support under the following scenarios and run derbyall cleanly against the built jars under both jdk1.4 and jdk1.6: 1) I have built the JDBC4 support using the 1.5 compiler and the 1.6 rt.jar. 2) I have built the JDBC4 support using the 1.5 compiler and the 1.5 rt.jar overlaid with an extension jar file containing the 1.6 JDBC packages (java.sql and javax.sql). However, to my non-lawyer's eye, neither of these approaches solves our legal problem because the Mustang license taints the libraries as well as the compiler. Regards, -Rick Jean T. Anderson wrote: Rick Hillegas wrote: Hi Dan, This looks to me like the license distributed with the current Mustang beta, which I used to generate the Derby 10.2.1.0 beta. Regards, -Rick I finally read the license at the link posted in the email below [1] and am immediately drawn to these paragraphs: 2.2 Binary Code. Sun grants to Licensee, a non-exclusive, non-transferable, royalty-free and limited license to use the binary code portions of the Licensed Software internally for the purposes of evaluation only. 3.5 Licensee shall have no right to use the Licensed Software for productive or commercial use. I'm concerned about these phrases: - limited license - internally - evaluation only - no right to use ... for productive use Can Mustang be used to build the Derby 10.2 release? Maybe I'm missing something, but it seems we're back to the same issue we had with JDBC 4.0. -jean [1] http://java.sun.com/javase/6/jdk-6-beta2-license.txt Daniel John Debrunner wrote: Andrew McIntyre wrote: On 8/14/06, Andrew McIntyre <[EMAIL PROTECTED]> wrote: While the licensing issue is definitely a problem for publishing the beta via the mirrors, it appears that the spec license has been updated. "While the licensing issue *was* definitely..." Is this the licence that Mustang is being used under in order to build the Derby 10.2 release? http://java.sun.com/javase/6/jdk-6-beta2-license.txt If not, is there a link to the download licence for Mustang? Thanks, Dan.
[jira] Commented: (DERBY-1734) Simplify building of SystemColumn array in CatalogRowFactory implementations.
[
http://issues.apache.org/jira/browse/DERBY-1734?page=comments#action_12429518 ]
Daniel John Debrunner commented on DERBY-1734:
--
5) No requirement to convert the case for column names, these classes are for
Derby's implementation of its system catalogs, and Derby uses a upper case for
system identifiers.
> Simplify building of SystemColumn array in CatalogRowFactory implementations.
> --
>
> Key: DERBY-1734
> URL: http://issues.apache.org/jira/browse/DERBY-1734
> Project: Derby
> Issue Type: Sub-task
>Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
>Priority: Minor
>
> The implementations of CatalogRowFactory.buildColumnList() can be simplified
> in a number of ways:
> 1) precision & scale are always passed in as zero and can be removed
>2) adding static factory methods to SystemColumnImpl would ease the
> building of the arrays by not requiring the additional redundant arguments
> the constructor call forces today, e.g. max length i snot required to create
> an INTEGER column.
> 3) The column's position is not required to be stored in the
> SytstemColumn class, it's defined by the position in the array
> 4) arrays can be built using
> new SystemColumn[] { ... }
> syntax instead of the existing
> columnList[0] = ...
> columnList[1] = ...
> or
> columnList[index++] = ...
> columnList[index++] = ...
>
--
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-1739) Index column names in CatalogRowFactory implementations are not required
Index column names in CatalogRowFactory implementations are not required Key: DERBY-1739 URL: http://issues.apache.org/jira/browse/DERBY-1739 Project: Derby Issue Type: Sub-task Components: SQL Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Priority: Minor The initInfo method of CatalogRowFactory takes a set of index column positions and index names. I was going to remove the passing of column names and instead get the names from the SystemColumn array returned by buildColumnList. Prior to that I added some code to check the existing index names passed in matched the names in the SystemColumn array and found there were mismatches, e.g. checking SYSCONGLOMERATES MISMATCH SYSCONGLOMERATES CONGLOMERATEID CONGLOMERATE_ID MISMATCH SYSCONGLOMERATES CONGLOMERATENAME CONGLOMERATE_NAME checking SYSSCHEMAS checking SYSCONSTRAINTS checking SYSKEYS checking SYSDEPENDS checking SYSALIASES checking SYSVIEWS checking SYSCHECKS checking SYSFOREIGNKEYS checking SYSSTATEMENTS MISMATCH SYSSTATEMENTS STMTID STATEMENTID checking SYSFILES checking SYSTRIGGERS MISMATCH SYSTRIGGERS TABLEID CREATIONTIMESTAMP Looking further to see why these mismatches did not cause problems or what hdden problems they might be causing I found they are stored in an IndexInfoImpl class but never used. -- 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: drop column functionality
On 8/21/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote: > 3. The version from trunk does not appear able to read databases created > with the 10.1.3.1 release. Has the database file syntax changed? I'm hoping one of the other developers can help with this question. I think that this is on purpose, to avoid accidentally mixing releases that may differ in major ways, but I think there is a configuration flag that you can set that will authorize the trunk code to open and read a previous-release database. Can anybody help us out here? How can Tim use some of his 10.1 databases in experimenting with a patched release built from the trunk? Setting "derby.database.allowPreReleaseUpgrade" system property to true will allow pre-release code (like trunk code) to read databases from previous release. Note that this property is only to be used for testing. Please take a look at these links for additional info: http://www.nabble.com/Re%3A-Soft-Upgrade-question-p3441560.html http://wiki.apache.org/db-derby/UpgradingTen Thanks, Deepa
[jira] Closed: (DERBY-1738) An user is able to grant select privilege on a view but the underlying object is not own by the user.
[ http://issues.apache.org/jira/browse/DERBY-1738?page=all ] Yip Ng closed DERBY-1738. - Resolution: Duplicate Duplicate to DERBY-1686, link DERBY-1686 to DERBY-1330. > An user is able to grant select privilege on a view but the underlying object > is not own by the user. > - > > Key: DERBY-1738 > URL: http://issues.apache.org/jira/browse/DERBY-1738 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.0 > Environment: Sun JDK 1.4.2 >Reporter: Yip Ng > > An user is able to grant select privilege on a view but the underlying object > is not own by the user. The grant statement should fail since the user does > not have privilege to grant. i.e.: > ij version 10.3 > ij> connect 'jdbc:derby:wombat;create=true' user 'user1' as user1; > WARNING 01J01: Database 'wombat' not created, connection made to existing > database instead. > WARNING 01J14: SQL authorization is being used without first enabling > authentication. > ij> create table t1 (i int); > ERROR X0Y32: Table/View 'T1' already exists in Schema 'USER1'. > ij> insert into t1 values 1,2,3; > 3 rows inserted/updated/deleted > ij> grant select on t1 to user2; > 0 rows inserted/updated/deleted > ij> connect 'jdbc:derby:wombat' user 'user2' as user2; > WARNING 01J14: SQL authorization is being used without first enabling > authentication. > ij(USER2)> -- ok > create view v1 as select * from user1.t1; > ERROR X0Y32: Table/View 'V1' already exists in Schema 'USER2'. > ij(USER2)> -- attempt to grant this view to others, should fail since user2 > -- does not have grant privilege on object user1.t1 > grant select on user1.t1 to user3; > ERROR 2850C: User 'USER2' is not the owner of Table/View 'USER1'.'T1'. > ij(USER2)> -- expect error > grant select on v1 to user3; > 0 rows inserted/updated/deleted > ij(USER2)> > -- Java Information -- > Java Version:1.4.2_12 > Java Vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\j2re1.4.2_12 > Java classpath: classes;. > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > Java user name: Yip > Java user home: C:\Documents and Settings\Yip > Java user dir: C:\work3\derby\trunk > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\work3\derby\trunk\classes] 10.3.0.0 alpha - (1) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] > version: 10.3.0.0 alpha - (1) > Found support for locale: [es] > version: 10.3.0.0 alpha - (1) > Found support for locale: [fr] > version: 10.3.0.0 alpha - (1) > Found support for locale: [it] > version: 10.3.0.0 alpha - (1) > Found support for locale: [ja_JP] > version: 10.3.0.0 alpha - (1) > Found support for locale: [ko_KR] > version: 10.3.0.0 alpha - (1) > Found support for locale: [pt_BR] > version: 10.3.0.0 alpha - (1) > Found support for locale: [zh_CN] > version: 10.3.0.0 alpha - (1) > Found support for locale: [zh_TW] > version: 10.3.0.0 alpha - (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] Updated: (DERBY-1582) REVOKE statement does not generate a warning when no privileges are revoked.
[ http://issues.apache.org/jira/browse/DERBY-1582?page=all ] Deepa Remesh updated DERBY-1582: Attachment: d1582_v2_with_tests.diff Attaching patch 'd1582_v2_with_tests.diff' which raises a warning when no privileges are revoked by the revoke statement for a grantee. This patch handles the case when multiple grantees are specified and raises a warning for each grantee. It is same as the earlier v2 patch. It only adds additional tests suggested by Mamta. DERBY-1538 has handled the cases and added the tests I mentioned in "2) When a privilege is found but it cannot be revoked". So I have only added additional tests for revoking routine privileges. derbyall ran with no new failures. Please take a look at this patch. Thanks. > REVOKE statement does not generate a warning when no privileges are revoked. > > > Key: DERBY-1582 > URL: http://issues.apache.org/jira/browse/DERBY-1582 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.0 >Reporter: Daniel John Debrunner > Assigned To: Deepa Remesh > Attachments: d1582_v1.diff, d1582_v1.status, d1582_v2.diff, > d1582_v2.status, d1582_v2_with_tests.diff > > > SQL 2003 standard, section 12.7 , item 17 under general > rules indicates the statement completes with the condition 'warning ? > privilege not revoked.' when no matching privilege is revoked. -- 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-1582) REVOKE statement does not generate a warning when no privileges are revoked.
[ http://issues.apache.org/jira/browse/DERBY-1582?page=all ] Deepa Remesh updated DERBY-1582: Derby Info: [Patch Available] > REVOKE statement does not generate a warning when no privileges are revoked. > > > Key: DERBY-1582 > URL: http://issues.apache.org/jira/browse/DERBY-1582 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.0 >Reporter: Daniel John Debrunner > Assigned To: Deepa Remesh > Attachments: d1582_v1.diff, d1582_v1.status, d1582_v2.diff, > d1582_v2.status, d1582_v2_with_tests.diff > > > SQL 2003 standard, section 12.7 , item 17 under general > rules indicates the statement completes with the condition 'warning ? > privilege not revoked.' when no matching privilege is revoked. -- 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: Documentation Style Issue - semi-colon at the end of SQL statement examples
Laura Stewart <[EMAIL PROTECTED]> writes: > Hi - > Should there be a semi-colon at the end of the SQL statement examples > in the Derby documentation. In other documentation work that I have > done, this was the standard. I just wanted to check with the Derby > community to see what is appropriate for the Derby docs. If the example is shown in ij, it should be there. If it is just an example SQL statement, I think it should be written without a semicolon. -- Knut Anders
[jira] Commented: (DERBY-1674) Investigate reducing the number of classes & methods in DataDictionary used to represent system tables
[ http://issues.apache.org/jira/browse/DERBY-1674?page=comments#action_12429501 ] Daniel John Debrunner commented on DERBY-1674: -- Simple stats on class count and sizes in insane mode (from the classes folder, not size in the jar). Revision: 432856 Number of RowFactory classes 21 Size of RowFactory classes 169252 org/apache/derby/iapi/sql/dictionary Number of Dictionary api classes 47 Size of Dictionary api classes 216108 org/apache/derby/impl/sql/catalog Number of Catalog impl classes 36 Size of Catalog impl classes 360173 > Investigate reducing the number of classes & methods in DataDictionary used > to represent system tables > --- > > Key: DERBY-1674 > URL: http://issues.apache.org/jira/browse/DERBY-1674 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner >Priority: Minor > > Currently two classes exists for each system table, one to represent the > table (e.g.SYSTABLESRowFactory) , one to represent a row (e.g. > TableDescriptor) > Look at having a single row factory (CatalogRowFactory) and using > polymorphism (method overloading) on the descriptor objects to perform the > work > that is done today (e.g. converting a descriptor to and from a Row object). > In addition the DataDictionary has a specific method to drop each type of > unique descriptor (e.g. dropSPSDescriptor, dropAliasDescriptor) > Would it be possible to have a single > dropDescriptor(UniqueSQLObjectDescriptor) method and again use polymorphism > on the descriptors. -- 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: Documentation Style Issue - semi-colon at the end of SQL statement examples
Laura Stewart wrote:
Hi -
Should there be a semi-colon at the end of the SQL statement examples
in the Derby documentation. In other documentation work that I have
done, this was the standard. I just wanted to check with the Derby
community to see what is appropriate for the Derby docs.
I don't know if there's a "rule" for this in Derby docs, but it seems to me that
at some point someone somewhere pointed out that, technically, the semi-colon is
NOT part of the SQL statement. For example, I think if you include the
semi-colon at the end of a SQL statement in a JDBC call like:
ResultSet rs = st.executeQuery("SELECT * FROM T1;");
the result will be a syntax error caused by the presence of the semi-colon:
ERROR 42X01: Syntax error: Encountered ";" at line 1 ...
I think the semi-colon is a popular statement terminator for a lot of
command-line interfaces to databases, including Derby's own ij. But in the case
of ij the semi-colon is stripped off before the statement is actually passed to
the Derby engine, so it (the semi-colon) is really an ij requirement, not a SQL
statement requirement.
My personal answer to your question, then, would be that the semi-colon should
only be included if the doc is showing the example statement as it would be
executed in ij. So if the doc looked like:
ij> connect 'mydb';
ij> select * from t1;
I'd say include the semi-colon. But if the example is just an example of how to
select all the rows from t1 or an example of how to use the syntax for a Derby
SQL statement, I'd say leave the semicolon off:
select * from t1
FWIW,
Army
Re: [jira] Commented: (DERBY-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBina
TomohitoNakayama <[EMAIL PROTECTED]> writes: > Hello Knut. > > By the way, I want to figure it out what is the actual range of > modification in DERBY-1610. > > Knut Anders Hatlen commented on DERBY-1610: >>Therefore, I think that it is better to fix all of them at once. > > What is "all of them" here ? > > Just setBlob and setBinaryStream ? > Or whole case of parameterMapping.java ? I was thinking about all the setter methods. I think we only need a method in am/PreparedStatement which checks whether a given type is compatible with the type of the parameter, and a call to that method in PreparedStatement.checkSetterPreconditions(). > Too high goal may block other task, > then reasonable goal should be established. Good point! If we use a generic approach to begin with, we could add checks for a subset of the types and increase incrementally. I think that if we do it for setBinaryStream() we should also do it for setBlob() and setBytes() in the same run. Next (in a separate patch), we could do the same for setAsciiStream(), setCharacterStream() and setString(). Then we fix all the scalar setters (setInt, setFloat & co.), and finally date, time and timestamp. > I think it is needed to analyze current difference of > parameterMapping.out between Embedded and Network Client in order to > consider the goal... Sounds like a good idea. -- Knut Anders
[jira] Commented: (DERBY-1655) Document XML functionality for 10.2
[ http://issues.apache.org/jira/browse/DERBY-1655?page=comments#action_12429495 ] A B commented on DERBY-1655: > Okay to refer to it as a function instead of an operator? Great question. I guess I'm not sure what the answer here should be... I've been calling these "operators" because that's the term used in the SQL/XML[2006] specification. But the Derby doc says the following: "A built-in function is an expression in which an SQL keyword or special operator executes some operation." And the SQL/XML specification indicates XMLEXISTS, etc are reserved keywords. So based on that I guess it would be okay to refer to the new SQL/XML operators as Derby built-in functions, as well. My gut feeling, though, is that we should continue to use the term "operator" for these because a) that's the term used by the SQL/XML specification and b) I don't think we state anywhere that an "operator" cannot be a "function" as well. I am not going to complain one way or the other, though. If anyone else has a strong preference, feel free to speak up... > Document XML functionality for 10.2 > --- > > Key: DERBY-1655 > URL: http://issues.apache.org/jira/browse/DERBY-1655 > Project: Derby > Issue Type: Task > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: A B > Assigned To: Laura Stewart > Fix For: 10.2.1.0 > > Attachments: ctoolsimport27052.html, derby1655_devguide.diff, > derby1655_devguide_html.zip, derby1655_ref.diff, derby1655_ref_html.zip, > derby1655_tools_html.diff, derby1655_tuning.diff, derby1655_tuning_html.zip, > DerbyXMLDoc_v1.html, DerbyXMLDoc_v2.html > > > DERBY-334 and DERBY-688 have added an XML datatype and four XML operators to > Derby. These are all going to be exposed to the user for general use as part > of the 10.2. release, so the datatype and operators need to be documented > 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-418) outofmemory error when running large query in autocommit=false mode
> Not sure of the guarantee of the unsynchronized field being set. Are you > saying that field will never be seen as set, or that the setting may not be > seen for some time? > It may be seen, however it may also never be seen. Andreas
Re: [jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode
Knut Anders Hatlen wrote: > "Andreas Korneliussen (JIRA)" writes: > >> Assuming the Derby embedded JDBC driver is thread-safe, it should be >> safe for a result set to call its own close() method in its >> finalizer. If you get a dead-lock in the finalizer, it proves that >> it is also possible to write a multithreaded program which gets >> deadlocks when calling ResultSet.close, and derby then is not really >> MT-safe. >> >> If this happens, I think it is better to fix the embedded driver so >> that it really becomes MT-safe, than avoiding synchronization in the >> finalizer threads. > > There are calls to System.runFinalization() many places in the > code. If the thread that invokes System.runFinalization() has obtained > the same mutex that a finalize method requires, there can indeed be > deadlocks. (But I guess you will argue that we shouldn't call > runFinalization() explicitly.) > Yes. >> As for the suggested change in 1142, I would note that If there is >> no synchronization in the finalizer, and you set a field in a object >> from it, there is no guarantee that other threads will see the >> modification of the field (unless, I think, it is >> volatile). However, I think Mayuresh has been working on this issue, >> so maybe he has tried that approach? > > FWIW, I tried that approach in my sandbox (setting a volatile variable > in GenericLanguageConnectionContext from BaseActivation.markUnused()) > and I didn't see the OutOfMemoryError any more. It's a very simple > fix, and I don't think the overhead is noticeable, so I'd recommend > that we go for that solution. > Seems like a good idea. Andreas
[jira] Commented: (DERBY-1738) An user is able to grant select privilege on a view but the underlying object is not own by the user.
[ http://issues.apache.org/jira/browse/DERBY-1738?page=comments#action_12429488 ] Satheesh Bandaram commented on DERBY-1738: -- This is a duplicate of the issue Rajesh has already filed. I think that is DERBY-1686. > An user is able to grant select privilege on a view but the underlying object > is not own by the user. > - > > Key: DERBY-1738 > URL: http://issues.apache.org/jira/browse/DERBY-1738 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.0 > Environment: Sun JDK 1.4.2 >Reporter: Yip Ng > > An user is able to grant select privilege on a view but the underlying object > is not own by the user. The grant statement should fail since the user does > not have privilege to grant. i.e.: > ij version 10.3 > ij> connect 'jdbc:derby:wombat;create=true' user 'user1' as user1; > WARNING 01J01: Database 'wombat' not created, connection made to existing > database instead. > WARNING 01J14: SQL authorization is being used without first enabling > authentication. > ij> create table t1 (i int); > ERROR X0Y32: Table/View 'T1' already exists in Schema 'USER1'. > ij> insert into t1 values 1,2,3; > 3 rows inserted/updated/deleted > ij> grant select on t1 to user2; > 0 rows inserted/updated/deleted > ij> connect 'jdbc:derby:wombat' user 'user2' as user2; > WARNING 01J14: SQL authorization is being used without first enabling > authentication. > ij(USER2)> -- ok > create view v1 as select * from user1.t1; > ERROR X0Y32: Table/View 'V1' already exists in Schema 'USER2'. > ij(USER2)> -- attempt to grant this view to others, should fail since user2 > -- does not have grant privilege on object user1.t1 > grant select on user1.t1 to user3; > ERROR 2850C: User 'USER2' is not the owner of Table/View 'USER1'.'T1'. > ij(USER2)> -- expect error > grant select on v1 to user3; > 0 rows inserted/updated/deleted > ij(USER2)> > -- Java Information -- > Java Version:1.4.2_12 > Java Vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\j2re1.4.2_12 > Java classpath: classes;. > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > Java user name: Yip > Java user home: C:\Documents and Settings\Yip > Java user dir: C:\work3\derby\trunk > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\work3\derby\trunk\classes] 10.3.0.0 alpha - (1) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] > version: 10.3.0.0 alpha - (1) > Found support for locale: [es] > version: 10.3.0.0 alpha - (1) > Found support for locale: [fr] > version: 10.3.0.0 alpha - (1) > Found support for locale: [it] > version: 10.3.0.0 alpha - (1) > Found support for locale: [ja_JP] > version: 10.3.0.0 alpha - (1) > Found support for locale: [ko_KR] > version: 10.3.0.0 alpha - (1) > Found support for locale: [pt_BR] > version: 10.3.0.0 alpha - (1) > Found support for locale: [zh_CN] > version: 10.3.0.0 alpha - (1) > Found support for locale: [zh_TW] > version: 10.3.0.0 alpha - (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-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
[ http://issues.apache.org/jira/browse/DERBY-1292?page=comments#action_12429487 ] James F. Adams commented on DERBY-1292: --- The uploaded patch is ready for review. > ClassCastException in ClientDriver when using CLOB columns and batch updates > > > Key: DERBY-1292 > URL: http://issues.apache.org/jira/browse/DERBY-1292 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.1.2.1 >Reporter: Gerald Khin > Assigned To: James F. Adams > Attachments: DERBY-1292.diff > > > java.lang.ClassCastException: java.lang.String > at > org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown > Source) > at > org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown > Source) > at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown > Source) > at > org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source) > at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown > Source) > at > org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown > Source) > at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71) > at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27) -- 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-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
Andrew McIntyre wrote: > On 8/21/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > >> >> That is actually engine code, so should not be used by the tools (or the >> tests) > > > Yet there are references to JVMInfo in both ij and sysinfo. Should > these be removed, then? Or the code moved into the common area (and bring up that whole can of worms :-) > >> it would work for some cases (assuming the code was moved), but >> it doesn't handle J2ME/CDC/Foundation or J2ME/CLDC or Java Card. > > > Currently the code in JVMInfo assumes that a J2ME VM is 1.3 level, so > the code above would currently print an error and exit on those > platforms, would it not? No idea, might get a class not found error in starting up. As you say "assumes" is the key point, it assumes it's running in J2SE (or J2ME/CDC/Foundation). It doesn't cater to the fact it might be running in a less enabled environment so it may or may not handle that case. For example, if Derby ran against OSGi ee.minimum I'm pretty sure it wouldn't work and it wouldn't get a nice error message, since our error message handling relies on classes not in OSGi ee.minimum. Should someone fix that so that Derby produces a nice error message in OSGi ee.minimum (or CLDC or JavaCard etc.) ? I don't see it as a requirement. If someone submitted a patch that made it produce a nice error message in OSGi ee.minimum then maybe it would be committed, depends on how much cruft code would be needed to add very little value. In addition, the JDK_ID level produced by JVMInfo class is just designed for J2SE and it's Derby's interpretation, not any standard Java concept. Thus with: JVMInfo.JDK_ID < JVMInfo.J2SE_15 who knows what JVMInfo.JDK_ID would end up being on J2ME/CLDC or JavaCard, may end up being a value greater than JVMInfo.J2SE_15. Dan.
Re: [jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode
"Andreas Korneliussen (JIRA)" writes: > Assuming the Derby embedded JDBC driver is thread-safe, it should be > safe for a result set to call its own close() method in its > finalizer. If you get a dead-lock in the finalizer, it proves that > it is also possible to write a multithreaded program which gets > deadlocks when calling ResultSet.close, and derby then is not really > MT-safe. > > If this happens, I think it is better to fix the embedded driver so > that it really becomes MT-safe, than avoiding synchronization in the > finalizer threads. There are calls to System.runFinalization() many places in the code. If the thread that invokes System.runFinalization() has obtained the same mutex that a finalize method requires, there can indeed be deadlocks. (But I guess you will argue that we shouldn't call runFinalization() explicitly.) > As for the suggested change in 1142, I would note that If there is > no synchronization in the finalizer, and you set a field in a object > from it, there is no guarantee that other threads will see the > modification of the field (unless, I think, it is > volatile). However, I think Mayuresh has been working on this issue, > so maybe he has tried that approach? FWIW, I tried that approach in my sandbox (setting a volatile variable in GenericLanguageConnectionContext from BaseActivation.markUnused()) and I didn't see the OutOfMemoryError any more. It's a very simple fix, and I don't think the overhead is noticeable, so I'd recommend that we go for that solution. -- Knut Anders
[jira] Commented: (DERBY-1655) Document XML functionality for 10.2
[ http://issues.apache.org/jira/browse/DERBY-1655?page=comments#action_12429486 ] Laura Stewart commented on DERBY-1655: -- Regarding the new information about XMLEXISTS, you ask that it be put into the Built-in function section and yet you refer to it as an "operator". Unlike the concatenate operator (which to me is a symbol), XMLEXISTS is a function that accepts several arguments. Okay to refer to it as a function instead of an operator? > Document XML functionality for 10.2 > --- > > Key: DERBY-1655 > URL: http://issues.apache.org/jira/browse/DERBY-1655 > Project: Derby > Issue Type: Task > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: A B > Assigned To: Laura Stewart > Fix For: 10.2.1.0 > > Attachments: ctoolsimport27052.html, derby1655_devguide.diff, > derby1655_devguide_html.zip, derby1655_ref.diff, derby1655_ref_html.zip, > derby1655_tools_html.diff, derby1655_tuning.diff, derby1655_tuning_html.zip, > DerbyXMLDoc_v1.html, DerbyXMLDoc_v2.html > > > DERBY-334 and DERBY-688 have added an XML datatype and four XML operators to > Derby. These are all going to be exposed to the user for general use as part > of the 10.2. release, so the datatype and operators need to be documented > 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
Regression Test Failure! - TinderBox_Derby 433261 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 433261/2006-08-21 17:22:24 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1672671 2 149.26% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-433261.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/433261.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/433261.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: Re: [jira] Commented: (DERBY-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
On 8/21/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: That is actually engine code, so should not be used by the tools (or the tests) Yet there are references to JVMInfo in both ij and sysinfo. Should these be removed, then? it would work for some cases (assuming the code was moved), but it doesn't handle J2ME/CDC/Foundation or J2ME/CLDC or Java Card. Currently the code in JVMInfo assumes that a J2ME VM is 1.3 level, so the code above would currently print an error and exit on those platforms, would it not? andrew
Documentation Style Issue - semi-colon at the end of SQL statement examples
Hi - Should there be a semi-colon at the end of the SQL statement examples in the Derby documentation. In other documentation work that I have done, this was the standard. I just wanted to check with the Derby community to see what is appropriate for the Derby docs. -- Laura Stewart
[jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429483 ] Daniel John Debrunner commented on DERBY-418: - I'd assumed that you were going to go in at a lower level than ResultSet.close(). ResultSet.close() is thread safe, but think of the consequences of calling ResultSet.close() from a finalizer. - The finalizer thread will block until the application thread executing a JDBC method on another object in the same connection completes the call. Worst case is the application thread is executing a query that takes several hours. Now the synchronization in the finalize method has resulted in the finalize thread stalling for a few hours, not good for the VM. - What if the garbage collector thread is running because the application thread, using the same connection, requires memory, now you have created a deadlock , the application thread is waiting on the JVM to get memory, the vm finalizer thread is waiting on the application thread to complete its JDBC method call. Not sure of the guarantee of the unsynchronized field being set. Are you saying that field will never be seen as set, or that the setting may not be seen for some time? The activation being in the Vector is not an issue, so replacing it with a WeakHashMap doesn't help. Code needs to be executed against the activation in order to clean it up, just letting it be garbage collected is not enough. The current scheme was set up to be simple, only a single thread active in a connection at a single time, and to avoid the jvm deadlocks that wer seen when the activations were cleaned up directly in the finalize thread (since it breaks the simple rule, only a single thread active in a connection). > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(Gene
[jira] Commented: (DERBY-1547) Add svn version number to DatabaseMetaData getDatabaseProductVersion and getDriverVersion() to improve supportability
[ http://issues.apache.org/jira/browse/DERBY-1547?page=comments#action_12429478 ] Andrew McIntyre commented on DERBY-1547: "The above solution has been based on the suggestions received for this issue in using a property file as the point where the version information will be stored so that we no more need to update multiple master files when bumping version information but only replace one property file." We already have one properties file that contains the version number: tools/ant/properties/release.properties. We should not have another that needs updating when changing the version. I suggest that you generate your properties file from that file at build time. If the goal for this issue is now to completely remove the need to update master files when bumping the version, then the metadata tests that call getMajor/MinorVersion() and only output that part of the version would also need to be accounted for. That seems outside of the scope of this issue's description, though. > 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 > Assigned To: V.Narayanan >Priority: Minor > Fix For: 10.2.1.0 > > Attachments: DERBY-1547_v1.diff, DERBY-1547_v1.stat > > > 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. -- 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-1655) Document XML functionality for 10.2
[ http://issues.apache.org/jira/browse/DERBY-1655?page=comments#action_12429477 ] Laura Stewart commented on DERBY-1655: -- Hi Army - I am working on updating the dev guide now and will include these comments for the ref manual. I should have a patch out soon for you to review. > Document XML functionality for 10.2 > --- > > Key: DERBY-1655 > URL: http://issues.apache.org/jira/browse/DERBY-1655 > Project: Derby > Issue Type: Task > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: A B > Assigned To: Laura Stewart > Fix For: 10.2.1.0 > > Attachments: ctoolsimport27052.html, derby1655_devguide.diff, > derby1655_devguide_html.zip, derby1655_ref.diff, derby1655_ref_html.zip, > derby1655_tools_html.diff, derby1655_tuning.diff, derby1655_tuning_html.zip, > DerbyXMLDoc_v1.html, DerbyXMLDoc_v2.html > > > DERBY-334 and DERBY-688 have added an XML datatype and four XML operators to > Derby. These are all going to be exposed to the user for general use as part > of the 10.2. release, so the datatype and operators need to be documented > 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-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
Andrew McIntyre wrote:
> On 8/21/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
>
>> Andrew McIntyre wrote:
>>
>> > On 8/20/06, Satheesh Bandaram (JIRA) wrote:
>> >
>> >>
>> >> 3) Looks like the code uses generics, which limit the use to JDK 1.5
>> >> platforms. While this may be ok, need to document need for JDK 1.5
>> >> platform and raise appropriate message if used in earlier platforms.
>> >> Most of derby can still run on JDK 1.3 platforms, though not required
>> >> for new indepedent modules.
>> >
>> >
>> > As well as being documented, the tool should print a useful error and
>> > then exit if a user attempts to run it on an unsupported JVM.
>>
>> I wouldn't put that as a hard requirement. You can end up with some
>> amount of hard to understand code for no benefit. Do we really need to
>> test for jdk 1.0, 1.1?, 1.2? How about J2ME/CLDC? Java Card? How about
>> J2ME/CDC without foundation profile?
>>
>> Sometimes it's cleaner and easier just to state in the documentation
>> that it requires JDK 1.5 or higher and if someone tries to run it on an
>> unsupported platform that's their issue.
>
>
> Wouldn't:
>
> if (JVMInfo.JDK_ID < JVMInfo.J2SE_15) {
> ... print error and exit ...
> }
>
> cover all of those cases and be clear as to the intention, especially
> since there's an associated error message?
That is actually engine code, so should not be used by the tools (or the
tests), it would work for some cases (assuming the code was moved), but
it doesn't handle J2ME/CDC/Foundation or J2ME/CLDC or Java Card.
If someone wants to put the effort in, fine, but I don't think it should
be any requirement to do so.
Dan.
[jira] Commented: (DERBY-1655) Document XML functionality for 10.2
[ http://issues.apache.org/jira/browse/DERBY-1655?page=comments#action_12429474 ] Jean T. Anderson commented on DERBY-1655: - Committed to the trunk derby1655_tuning.diff (revision 433298) and derby1655_tools_html.diff (revision 433307). > Document XML functionality for 10.2 > --- > > Key: DERBY-1655 > URL: http://issues.apache.org/jira/browse/DERBY-1655 > Project: Derby > Issue Type: Task > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: A B > Assigned To: Laura Stewart > Fix For: 10.2.1.0 > > Attachments: ctoolsimport27052.html, derby1655_devguide.diff, > derby1655_devguide_html.zip, derby1655_ref.diff, derby1655_ref_html.zip, > derby1655_tools_html.diff, derby1655_tuning.diff, derby1655_tuning_html.zip, > DerbyXMLDoc_v1.html, DerbyXMLDoc_v2.html > > > DERBY-334 and DERBY-688 have added an XML datatype and four XML operators to > Derby. These are all going to be exposed to the user for general use as part > of the 10.2. release, so the datatype and operators need to be documented > 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-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429473 ] Andreas Korneliussen commented on DERBY-418: Assuming the Derby embedded JDBC driver is thread-safe, it should be safe for a result set to call its own close() method in its finalizer. If you get a dead-lock in the finalizer, it proves that it is also possible to write a multithreaded program which gets deadlocks when calling ResultSet.close, and derby then is not really MT-safe. If this happens, I think it is better to fix the embedded driver so that it really becomes MT-safe, than avoiding synchronization in the finalizer threads. As for the suggested change in 1142, I would note that If there is no synchronization in the finalizer, and you set a field in a object from it, there is no guarantee that other threads will see the modification of the field (unless, I think, it is volatile). However, I think Mayuresh has been working on this issue, so maybe he has tried that approach? Another approach could be to use a WeakHashMap to store the activations in, instead of a Vector. If all objects referring to the activation have been garbage collected, the activation will be removed from the WeakHashMap. > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database
Re: Re: [jira] Commented: (DERBY-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
On 8/21/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Andrew McIntyre wrote:
> On 8/20/06, Satheesh Bandaram (JIRA) wrote:
>
>>
>> 3) Looks like the code uses generics, which limit the use to JDK 1.5
>> platforms. While this may be ok, need to document need for JDK 1.5
>> platform and raise appropriate message if used in earlier platforms.
>> Most of derby can still run on JDK 1.3 platforms, though not required
>> for new indepedent modules.
>
>
> As well as being documented, the tool should print a useful error and
> then exit if a user attempts to run it on an unsupported JVM.
I wouldn't put that as a hard requirement. You can end up with some
amount of hard to understand code for no benefit. Do we really need to
test for jdk 1.0, 1.1?, 1.2? How about J2ME/CLDC? Java Card? How about
J2ME/CDC without foundation profile?
Sometimes it's cleaner and easier just to state in the documentation
that it requires JDK 1.5 or higher and if someone tries to run it on an
unsupported platform that's their issue.
Wouldn't:
if (JVMInfo.JDK_ID < JVMInfo.J2SE_15) {
... print error and exit ...
}
cover all of those cases and be clear as to the intention, especially
since there's an associated error message?
andrew
[jira] Created: (DERBY-1738) An user is able to grant select privilege on a view but the underlying object is not own by the user.
An user is able to grant select privilege on a view but the underlying object is not own by the user. -- Key: DERBY-1738 URL: http://issues.apache.org/jira/browse/DERBY-1738 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Sun JDK 1.4.2 Reporter: Yip Ng An user is able to grant select privilege on a view but the underlying object is not own by the user. The grant statement should fail since the user does not have privilege to grant. i.e.: ij version 10.3 ij> connect 'jdbc:derby:wombat;create=true' user 'user1' as user1; WARNING 01J01: Database 'wombat' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij> create table t1 (i int); ERROR X0Y32: Table/View 'T1' already exists in Schema 'USER1'. ij> insert into t1 values 1,2,3; 3 rows inserted/updated/deleted ij> grant select on t1 to user2; 0 rows inserted/updated/deleted ij> connect 'jdbc:derby:wombat' user 'user2' as user2; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(USER2)> -- ok create view v1 as select * from user1.t1; ERROR X0Y32: Table/View 'V1' already exists in Schema 'USER2'. ij(USER2)> -- attempt to grant this view to others, should fail since user2 -- does not have grant privilege on object user1.t1 grant select on user1.t1 to user3; ERROR 2850C: User 'USER2' is not the owner of Table/View 'USER1'.'T1'. ij(USER2)> -- expect error grant select on v1 to user3; 0 rows inserted/updated/deleted ij(USER2)> -- Java Information -- Java Version:1.4.2_12 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\j2re1.4.2_12 Java classpath: classes;. OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: Yip Java user home: C:\Documents and Settings\Yip Java user dir: C:\work3\derby\trunk java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\work3\derby\trunk\classes] 10.3.0.0 alpha - (1) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.3.0.0 alpha - (1) Found support for locale: [es] version: 10.3.0.0 alpha - (1) Found support for locale: [fr] version: 10.3.0.0 alpha - (1) Found support for locale: [it] version: 10.3.0.0 alpha - (1) Found support for locale: [ja_JP] version: 10.3.0.0 alpha - (1) Found support for locale: [ko_KR] version: 10.3.0.0 alpha - (1) Found support for locale: [pt_BR] version: 10.3.0.0 alpha - (1) Found support for locale: [zh_CN] version: 10.3.0.0 alpha - (1) Found support for locale: [zh_TW] version: 10.3.0.0 alpha - (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
Re: [jira] Commented: (DERBY-1655) Document XML functionality for 10.2
A B (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/DERBY-1655?page=comments#action_12429467 > ] > > A B commented on DERBY-1655: > > > Thank you Laura for taking the time to port the doc changes in _v1.html into > the Derby 10.2 manuals. > > The changes in: > > derby1655_tuning.diff > derby1655_tools_html.diff > > look good to me and can be committed (+1). I'll commit these. -jean
[jira] Commented: (DERBY-1655) Document XML functionality for 10.2
[
http://issues.apache.org/jira/browse/DERBY-1655?page=comments#action_12429467 ]
A B commented on DERBY-1655:
Thank you Laura for taking the time to port the doc changes in _v1.html into
the Derby 10.2 manuals.
The changes in:
derby1655_tuning.diff
derby1655_tools_html.diff
look good to me and can be committed (+1).
The changes in
derby1655_devguide.diff
are still awaiting some slight updates per my previous comment.
And below I've include a couple of (very) minor comments on the changes in the
Reference Guide, i.e. the changes in:
derby1655_ref.diff
NOTE: Most of these are minor enough to be left as they are, with the exception
of those tagged with "##!##". So if you are short on time, feel free to skip
the minor changes and just focus on the changes tagged with "##!##".
File: rrefjdbcrefsqlxml.html
-- 1 --
Slight typo: can remove "to" just before "retrieve an XML" in the following
sentence:
You cannot instantiate a java.sql.SQLXML object in Derby,
or bind directly into an XML value or to retrieve an XML
value directly from a result set.
Suggested rewording (optional):
You cannot instantiate a java.sql.SQLXML object in Derby.
You also cannot bind directly into an XML value or retrieve
an XML value directly from a result set.
File: rrefsqljtypexml.html
--
-- 1 --
Comment: Can we explicitly mention XMLPARSE and XMLSERIALIZE in the following
sentence, like we do in rrefjdbcrefsqlxml.html?
Instead, you must bind and retrieve the XML data as Java
strings or character streams by explicitly specifying the
appropriate XML operators as part of your SQL queries.
Suggested rewording (optional):
Instead, you must bind and retrieve the XML data as Java
strings or character streams by explicitly specifying the
appropriate XML operators, XMLPARSE and XMLSERIALIZE, as
part of your SQL queries.
-- 2 --
Slight typo: Comma between the following two sentences should be a period:
The Java type for XML values is java.sql.SQLXML, The
java.sql.SQLXML type is not supported by Derby.
Suggested addition (optional): can we add the word "However" at the start of
the second sentence? And also at the start of the second sentence in this line:
The metadata type for XML values is SQLXML. The SQLXML type
is not supported by Derby.
-- 3 -- ##!##
Syntax update: One of the latest checkins for XML ("phase 4" patch) added a
restriction to the use of parameters in XMLPARSE, so the example in this file
needs to be updated. In particular, change
INSERT INTO myXmlTable(xcol) VALUES XMLPARSE(
DOCUMENT ? PRESERVE WHITESPACE)
to be
INSERT INTO myXmlTable(xcol) VALUES XMLPARSE (
DOCUMENT CAST (? AS CLOB) PRESERVE WHITESPACE)
File: rreflimitsxml.html
-- 1 --
Slight typo: replace "are in the classpath" with "to be in the classpath" in
the following sentence:
Requires the JAXP parser classes, such as Apache Xerces, and
Apache Xalan classes are in the classpath. Attempts to use XML
operators without these classes in the classpath results in an
error.
File: rrefsqlj33562.html
-- 1 -- ##!##
Comment: The XML row has dashes in it, which is correct. However the XML
column just has blank cells. Can we add dashes to the cells in the XML column,
as well, to be consistent with the rest of the table?
And that's it! Thanks for being so thorough with these.
> Document XML functionality for 10.2
> ---
>
> Key: DERBY-1655
> URL: http://issues.apache.org/jira/browse/DERBY-1655
> Project: Derby
> Issue Type: Task
> Components: Documentation
>Affects Versions: 10.2.1.0
>Reporter: A B
> Assigned To: Laura Stewart
> Fix For: 10.2.1.0
>
> Attachments: ctoolsimport27052.html, derby1655_devguide.diff,
> derby1655_devguide_html.zip, derby1655_ref.diff, derby1655_ref_html.zip,
> derby1655_tools_html.diff, derby1655_tuning.diff, derby1655_tuning_html.zip,
> DerbyXMLDoc_v1.html, DerbyXMLDoc_v2.html
>
>
> DERBY-334 and DERBY-688 have added an XML datatype and four XML operators to
> Derby. These are all going to be exposed to the user for general use as part
> of the 10.2. release, so the datatype and operators need to be documented
> 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-1489) Provide ALTER TABLE DROP COLUMN functionality
[ http://issues.apache.org/jira/browse/DERBY-1489?page=comments#action_12429465 ] Bryan Pendleton commented on DERBY-1489: Derby user Tim Dudgeon has been successfully experimenting with this patch, see: http://www.nabble.com/drop-column-functionality-tf2141055.html#a5910820 > 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.1.0, 10.1.2.1, > 10.1.3.0, 10.1.3.1 >Reporter: Bryan Pendleton > Assigned To: Bryan Pendleton > 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] Resolved: (DERBY-1622) Add documentation for encrypted database using encryptionKey
[ http://issues.apache.org/jira/browse/DERBY-1622?page=all ] Jean T. Anderson resolved DERBY-1622. - Fix Version/s: 10.3.0.0 (was: 10.2.1.0) Resolution: Fixed Derby Info: (was: [Patch Available]) Committed patch derby1622_devguide_5.diff to trunk, revision 433290. > 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.1.0 >Reporter: Sunitha Kambhampati > Assigned To: Laura Stewart >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: derby1622.diff, derby1622_2.diff, derby1622_3.diff, > derby1622_4.diff, derby1622_devguide_5.diff, Derby1622_html.zip, > derby1622_html2.zip, derby1622_html3.zip, derby1622_html4.zip, > derby1622_html5.zip > > > 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
Re: drop column functionality
1. Dropping the column seems very slow for large tables. This is good to know. I don't think anybody has really experimented with this yet. Can you quantify "very slow" with some real measurements you've taken? Do you think it would be reasonable to treat this as a follow-on improvement to the DERBY-1489 changes, or do you feel that the performance is so bad that DERBY-1489 is unusable as is? I guess my assumption was that DROP COLUMN usage in large database scenarios would be rare, and that it would be more common for people to want to use DROP COLUMN during their initial application development, when tables are typically smaller. But perhaps this is a bad assumption? If you think this would be reasonable to treat as a follow-on improvement, then please open a new JIRA issue for it, describe it as well as you can with the data you can provide, and link the new issue to DERBY-1489 so that we know they're related. 2. I'm reluctant to use the SVN trunk in my application, preferring a stable release. Are there any plans for when this patch will get into a stable release. In general, I think the process is something like: - the community reviews the DERBY-1489 changes (that's underway now) - those changes get committed to the trunk - those changes could appear in future release branches, or could be back-ported to patch release of prior release branches. I think we typically would *not* back-port a new feature to a prior release branch, so the DERBY-1489 changes would probably next appear in a stable release in the next release after they are committed to the trunk. However, I believe there's nothing that prevents you from constructing this yourself. You can take the 10.1 source code, and apply the trunk patch for DROP COLUMN to it, and create your own version of Derby which is "10.1 with DROP COLUMN functionality". I believe that the DERBY-1489 changes can be successfully applied to the 10.1 source base without too much work. 3. The version from trunk does not appear able to read databases created with the 10.1.3.1 release. Has the database file syntax changed? I'm hoping one of the other developers can help with this question. I think that this is on purpose, to avoid accidentally mixing releases that may differ in major ways, but I think there is a configuration flag that you can set that will authorize the trunk code to open and read a previous-release database. Can anybody help us out here? How can Tim use some of his 10.1 databases in experimenting with a patched release built from the trunk? thanks, bryan
[jira] Commented: (DERBY-1717) Working With Derby task file twwdactivity4.dita is invalid, results in missing text
[ http://issues.apache.org/jira/browse/DERBY-1717?page=comments#action_12429449 ] Stan Bradbury commented on DERBY-1717: -- Better late than never: I reviewed the revised section and the rework looks great. Thanks Kim for your attention in resolving the format problems. > Working With Derby task file twwdactivity4.dita is invalid, results in > missing text > --- > > Key: DERBY-1717 > URL: http://issues.apache.org/jira/browse/DERBY-1717 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.0 >Reporter: Kim Haase > Assigned To: Kim Haase >Priority: Minor > Fix For: 10.2.1.0 > > Attachments: twwdactivity4.dita.diff, twwdactivity4.html > > > The Working With Derby section > http://db.apache.org/derby/docs/dev/workingwithderby/twwdactivity4.html is > missing some text: a coded tag, "Running the client program," > disappears from the output. > This happens because the source file twwdactivity4.dita plays tricks with > DITA to try to get three subsections into a task topic, which does not allow > subsections. The last of the intended subsection titles fails to appear in > the output because it is coded as a second element in an , > which can have only one . (Ant warns about this during processing.) > And the two titles that do appear are different sizes because one is an > example title and the other just a paragraph in bold text. > To be valid DITA, this topic should be coded as a three-step task, where each > step has a series of substeps. I have taken the liberty of doing this. I have > also taken the liberty of correcting the punctuation and syntax problems that > I found. I am attaching a proposed patch. It looks pretty hairy because of > all the changes, I'm afraid. However, it is now valid DITA and shows the task > steps clearly. I am attaching the output that results, for comparison with > the original so you can see the substance is the same. -- 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-1622) Add documentation for encrypted database using encryptionKey
[ http://issues.apache.org/jira/browse/DERBY-1622?page=comments#action_12429448 ] Sunitha Kambhampati commented on DERBY-1622: Thanks Laura for the updates. Changes in derby1622_html5.zip look good and can be committed. > 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.1.0 >Reporter: Sunitha Kambhampati > Assigned To: Laura Stewart >Priority: Minor > Fix For: 10.2.1.0 > > Attachments: derby1622.diff, derby1622_2.diff, derby1622_3.diff, > derby1622_4.diff, derby1622_devguide_5.diff, Derby1622_html.zip, > derby1622_html2.zip, derby1622_html3.zip, derby1622_html4.zip, > derby1622_html5.zip > > > 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
Re: [jira] Updated: (DERBY-1622) Add documentation for encrypted database using encryptionKey
Laura Stewart (JIRA) wrote: > [ http://issues.apache.org/jira/browse/DERBY-1622?page=all ] > > Laura Stewart updated DERBY-1622: > - > > Attachment: derby1622_html5.zip > derby1622_devguide_5.diff > > Updated file tdevdvlp40140 per comments received. > > I thought that file tdevdvlpcreateencryptdbextkey had been committed before, > but when I do an SVN update, it appears that it didn't take from the last > patch. So it appears in this patch. I'll commit this. -jean
[jira] Updated: (DERBY-1622) Add documentation for encrypted database using encryptionKey
[ http://issues.apache.org/jira/browse/DERBY-1622?page=all ] Laura Stewart updated DERBY-1622: - Derby Info: [Patch Available] > 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.1.0 >Reporter: Sunitha Kambhampati > Assigned To: Laura Stewart >Priority: Minor > Fix For: 10.2.1.0 > > Attachments: derby1622.diff, derby1622_2.diff, derby1622_3.diff, > derby1622_4.diff, derby1622_devguide_5.diff, Derby1622_html.zip, > derby1622_html2.zip, derby1622_html3.zip, derby1622_html4.zip, > derby1622_html5.zip > > > 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] Updated: (DERBY-1622) Add documentation for encrypted database using encryptionKey
[ http://issues.apache.org/jira/browse/DERBY-1622?page=all ] Laura Stewart updated DERBY-1622: - Attachment: derby1622_html5.zip derby1622_devguide_5.diff Updated file tdevdvlp40140 per comments received. I thought that file tdevdvlpcreateencryptdbextkey had been committed before, but when I do an SVN update, it appears that it didn't take from the last patch. So it appears in this patch. > 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.1.0 >Reporter: Sunitha Kambhampati > Assigned To: Laura Stewart >Priority: Minor > Fix For: 10.2.1.0 > > Attachments: derby1622.diff, derby1622_2.diff, derby1622_3.diff, > derby1622_4.diff, derby1622_devguide_5.diff, Derby1622_html.zip, > derby1622_html2.zip, derby1622_html3.zip, derby1622_html4.zip, > derby1622_html5.zip > > > 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] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429442 ] Daniel John Debrunner commented on DERBY-418: - The alternate way to phrase it is: Can you guarantee no deadlocks from using synchronization in the finalize method? Closing an activation in the finalize() methods is going to hit a lot of synchronized blocks, there just seems endless potential for deadlocks, especially when the connection may be in any state, not being used, rolling back, preparing a statement, executing a statement, being shutdown by an unrelated error, being finalized itself, etc. etc.. This is then further compilcated by the fact the the order of execution within finalization is not guaranteed, if I have a chain of objects A,B,C the order they are finalized is not guaranteed, could be BAC, could be CBA, could be by different finalize threads. So given that, how easy is it to show the locking ordering is consistent? If you prove there is no possible chance of deadlocks, how is this enforced going forward? Does every change to any sycnhronized block have to go through a full review of possible implications with a single finalize method in EmbededResultSet? Maybe it's just me, but getting no synchronization in a finalize() method seems to be a nice simple rule, that doesn't require a proof for on-going changes in the engine. I suggested some possible changes to fix this in DERBY-1142 and noted them above, are there any issues with those? > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java)
[jira] Reopened: (DERBY-1622) Add documentation for encrypted database using encryptionKey
[ http://issues.apache.org/jira/browse/DERBY-1622?page=all ] Laura Stewart reopened DERBY-1622: -- Need to add one more fix > 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.1.0 >Reporter: Sunitha Kambhampati > Assigned To: Laura Stewart >Priority: Minor > Fix For: 10.2.1.0 > > Attachments: derby1622.diff, derby1622_2.diff, derby1622_3.diff, > derby1622_4.diff, Derby1622_html.zip, derby1622_html2.zip, > derby1622_html3.zip, derby1622_html4.zip > > > 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
Re: beta snapshot download from the website
Jean T. Anderson wrote: > Rick Hillegas wrote: ... >>>Also noticed that on the download page in the left panel, derby >>>10.1.2.1 is listed instead of 10.1.3.1. > > Good catch -- and where to correct that isn't obvious. Here is the file: > >derby/site/trunk/src/documentation/content/xdocs/site.xml > > It has this entry: > > href="releases/release-10.1.2.1.cgi"/> ... > In fact, I'd recommend just removing that line since the latest download > is in the table of contents for that page. I removed the entry from the site.xml file. -jean
[jira] Updated: (DERBY-1678) Track changes to 10.2 branch needed to build candidates
[ http://issues.apache.org/jira/browse/DERBY-1678?page=all ] Rick Hillegas updated DERBY-1678: - Attachment: derby-1678-10.2-bumpVersionNumbers_v03.diff Committing derby-1678-10.2-bumpVersionNumbers_v03.diff, bumping the last digit of the version id after generating the beta candidate. Committed at subversion revision 433268. > Track changes to 10.2 branch needed to build candidates > --- > > Key: DERBY-1678 > URL: http://issues.apache.org/jira/browse/DERBY-1678 > Project: Derby > Issue Type: Task >Affects Versions: 10.2.1.0 >Reporter: Rick Hillegas > Assigned To: Rick Hillegas > Fix For: 10.2.1.0 > > Attachments: derby-1678-10.2-bumpVersionNumbers_v03.diff, > derby-1678-10.2_bumpVersionNumbers.diff, > derby-1678-10.2_bumpVersionNumbers_v02.diff > > > Placeholder for hanging patches for beta/release generation. -- 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-1387) Add JMX extensions to Derby
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sanket Sharma wrote: > On 8/21/06, Andreas Korneliussen (JIRA) wrote: >>[ >> http://issues.apache.org/jira/browse/DERBY-1387?page=comments#action_12429432 >> ] >> >> Andreas Korneliussen commented on DERBY-1387: >> - >> >> Hi, thanks for providing this patch. I have tried compiling it, and I >> do have the following comments: >> >> 1. It seems that most of the classes have multiple entries in the >> patch file, so when applying the patch, I got the same class multiple >> times in the same file. > > I'm not able to follow what you are trying to point out. Are you > referring to the imports? Can you please explain so that I may look > back at the patch and correct? This is the first time I've submitted > anything using svn diff. Any help would be appriciated. > The same file seems to be added multiple times in the patch file. I.e on line 13 the class MBeanFactory is added: Index: java/engine/org/apache/derby/iapi/services/mbeans/MBeanFactory.java === - --- java/engine/org/apache/derby/iapi/services/mbeans/MBeanFactory.java (revision 0) +++ java/engine/org/apache/derby/iapi/services/mbeans/MBeanFactory.java (revision 0) @@ -0,0 +1,161 @@ this is repeated in line 372: Index: java/engine/org/apache/derby/iapi/services/mbeans/MBeanFactory.java === - --- java/engine/org/apache/derby/iapi/services/mbeans/MBeanFactory.java (revision 0) +++ java/engine/org/apache/derby/iapi/services/mbeans/MBeanFactory.java (revision 0) @@ -0,0 +1,161 @@ A possible reason, could be: a, you did svn diff >> filename.diff instead of svn diff > filename.diff b, my download is corrupt Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6ddi36DpyYjYNyIRApp8AJ0WfizxdQ/YvoNyvkTQSFQJdOQ9igCfZVGN SZ16uxx2gI4C8HISjFqOaXY= =ef2Q -END PGP SIGNATURE-
Re: 10.2 branch version number wrong?
Hi Dan, Thanks for pointing this out. I will bump the last digit now. Regards, -Rick Daniel John Debrunner wrote: Since there was a snapshot off the 10.2 branch, shouldn't its current version be 10.2.1.1 beta? I thought after a snapshot the normal practice was to bump the last digit. Maybe that step is not in the instructions? Dan.
drop column functionality
This is a continuation of a discussion on the users mailing list which I was advised to transfer here. See: http://thread.gmane.org/gmane.comp.apache.db.derby.user/4836/focus=4836 I've applied the patch for dropping columns and confirmed it works in a basic scenario. Here are some follow up questions/issues: 1. Dropping the column seems very slow for large tables. I suppose this is inevitable as lots of data needs to be deleted. But are improvements possible? 2. I'm reluctant to use the SVN trunk in my application, preferring a stable release. Are there any plans for when this patch will get into a stable release. 3. The version from trunk does not appear able to read databases created with the 10.1.3.1 release. Has the database file syntax changed? Thanks Tim
[jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429438 ] Andreas Korneliussen commented on DERBY-418: I am not sure what you mean. Could you give an example ? I agree that it is possible to get a deadlock in the finalize() method if it obtains its locks in a different order than another user thread or another finalizer thread. If it obtains the locks in the same order, the condition for a deadlock is not there. If there are multiple objects being garbage collected, sharing mutexes, they need to set the locks in the same order - or else you may get deadlock. > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(Updat
[jira] Created: (DERBY-1737) Network Server should check for current open and active connections before shutting down a database
Network Server should check for current open and active connections before shutting down a database --- Key: DERBY-1737 URL: http://issues.apache.org/jira/browse/DERBY-1737 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.0.2.0 Environment: Any Reporter: Rajesh Kartha Attachments: shutdown.sql, shutdown_embed.sql When a database shutdown is issued using the 'shutdown=true' by a client, the network server does not check for any active connections and shuts down the respective database. As a result queries on the active connection start failing. I would expect the right behaviour should be to throw an error mentioning shutdown was not performed since there are open connections to the database. Here is a sample output: ij version 10.2 ij> connect 'jdbc:derby://localhost:1527/testdb;create=true' as connA; ij> drop table t; 0 rows inserted/updated/deleted ij> create table t (id int); 0 rows inserted/updated/deleted ij> insert into t values (1); 1 row inserted/updated/deleted ij> insert into t values (2); 1 row inserted/updated/deleted ij> select * from t; ID --- 1 2 2 rows selected -- --Connection A is still open -- ij> connect 'jdbc:derby://localhost:1527/testdb' as connB; ij(CONNB)> insert into t values (3); 1 row inserted/updated/deleted ij(CONNB)> select * from t; ID --- 1 2 3 3 rows selected -- -- Should error out saying there are open connections to the database -- ij(CONNB)> connect 'jdbc:derby://localhost:1527/testdb;shutdown=true'; ERROR 08006: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08006, SQLERRMC: Database 'testdb' shutdown. ij(CONNB)> disconnect; -- --Connection A is still open -- ij> show connections; CONNA - jdbc:derby://localhost:1527/testdb;create=true No current connection -- --Set connection to connection A -- ij> set connection connA; -- --Try a sql -- ij> select * from t; ERROR 58009: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message ij> This issue kind of exists in embeddded also but since the database was booted in the same JVM, one can argue there is more control on the connections made to the database from the current JVM. In embedded the ''shutdown=true' closes all active connections to the database. ij(CONNB)> connect 'jdbc:derby:testdb;shutdown=true'; ERROR 08006: Database 'testdb' shutdown. ij(CONNB)> disconnect; -- -- Shows no current connections after a shutdown -- ij> show connections; No current connection ij> set connection connA; IJ ERROR: No connection exists with the name CONNA ij> select * from t; IJ ERROR: Unable to establish connection ij> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (22 issues) Subscriber: derby-dev Key Summary DERBY-1633 Regression: The fields of views are not being calculated properly since 10.1.2.4 http://issues.apache.org/jira/browse/DERBY-1633 DERBY-1559 when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB http://issues.apache.org/jira/browse/DERBY-1559 DERBY-1708 Unprivileged user can perform lock table statement on a table which he/she does not have any access rights http://issues.apache.org/jira/browse/DERBY-1708 DERBY-1651 Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options. http://issues.apache.org/jira/browse/DERBY-1651 DERBY-1500 PreparedStatement#setObject(int parameterIndex, Object x) throws SQL Exception when binding Short value in embedded mode http://issues.apache.org/jira/browse/DERBY-1500 DERBY-883 Enhance GROUP BY clause to support expressions instead of just column references. http://issues.apache.org/jira/browse/DERBY-883 DERBY-1636 document encryption of an un-encrypted database and re-encryption with new password/key. http://issues.apache.org/jira/browse/DERBY-1636 DERBY-801 Allow parallel access to data files. http://issues.apache.org/jira/browse/DERBY-801 DERBY-1292 ClassCastException in ClientDriver when using CLOB columns and batch updates http://issues.apache.org/jira/browse/DERBY-1292 DERBY-1405 New javadoc needs to be wired into documentation http://issues.apache.org/jira/browse/DERBY-1405 DERBY-1130 Client should not allow databaseName to be set with setConnectionAttributes http://issues.apache.org/jira/browse/DERBY-1130 DERBY-1655 Document XML functionality for 10.2 http://issues.apache.org/jira/browse/DERBY-1655 DERBY-119 Add ALTER TABLE option to change column from NULL to NOT NULL http://issues.apache.org/jira/browse/DERBY-119 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 DERBY-1473 Add cut-off and truncation logic to streaming classes in the embedded driver http://issues.apache.org/jira/browse/DERBY-1473 DERBY-889 with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date http://issues.apache.org/jira/browse/DERBY-889 DERBY-1659 Document describe and show tables functionality http://issues.apache.org/jira/browse/DERBY-1659 DERBY-1417 Add new, lengthless overloads to the streaming api http://issues.apache.org/jira/browse/DERBY-1417 DERBY-1643 A "revoke execute ... restrict" should fail if there are dependent objects on the execute privilege http://issues.apache.org/jira/browse/DERBY-1643 DERBY-815 Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() http://issues.apache.org/jira/browse/DERBY-815 DERBY-646 In-memory backend storage support http://issues.apache.org/jira/browse/DERBY-646 DERBY-1194 Derby Server and Administration Guide - Managing the Derby Network Server http://issues.apache.org/jira/browse/DERBY-1194
[jira] Updated: (DERBY-1730) Manifest file doesn't contain OSGi attributes
[ http://issues.apache.org/jira/browse/DERBY-1730?page=all ]
Rick Hillegas updated DERBY-1730:
-
Urgency: Urgent (was: Normal)
> Manifest file doesn't contain OSGi attributes
> -
>
> Key: DERBY-1730
> URL: http://issues.apache.org/jira/browse/DERBY-1730
> Project: Derby
> Issue Type: Bug
> Components: Build tools
>Affects Versions: 10.2.1.0
>Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Fix For: 10.2.1.0
>
> Attachments: manifest.diff
>
>
> I see this after the check-in of DERBY-1362. With osgi.jar in tools/java,
> 'ant buildjars' does not add the OSGi attributes to derby.jar's manifest.
> Instead, a file named ${manifest.file} is created in the root of the source
> tree. This file contains what should have been in the manifest, for instance:
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: diablo-1.5.0_07-b00 (Sun Microsystems Inc.)
> Bundle-Activator: org.apache.derby.osgi.EmbeddedActivator
> DynamicImport-Package: *
> Export-Package: org.apache.derby.authentication,org.apache.derby.datab
> ase,org.apache.derby.io,org.apache.derby.jdbc,org.apache.derby.vti
> This seems to be caused by build.xml containing a reference to
> "${manifest.file}" at a location where manifest.file is not bound to a value.
> The attached patch (manifest.diff) fixes the issue by replacing
> "${manifest.file}" with "${derby.jar.dir}/lists/smf.mf".
--
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
