http://blog.gmane.org/gmane.comp.apache.db.derby.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95717 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13283818#comment-13283818 ] Dag H. Wanvik commented on DERBY-118: ------------------------------------- And, yes, there is a race condition at midnight in the test when I assert current date.. ;-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-25T23:36:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95716 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-118: -------------------------------- Attachment: derby-118c.stat derby-118c.diff Uplaoding version "c", now with tests. Note that if the column is LONG VARCHAR we do not allow date-time coercion, as that implicit coercion is forbidden even on INSERT with an explicit VALUES (&lt;builtin datetime function&gt;), not sure why, cf. logic in CharTypeCompiler#convertible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-25T23:28:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95715 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-118: -------------------------------- Issue &amp; fix info: Patch Available -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-25T22:34:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95714 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-118: -------------------------------- Attachment: derby-118b.stat derby-118b.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-25T22:34:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95713 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13283788#comment-13283788 ] Dag H. Wanvik commented on DERBY-118: ------------------------------------- Uploading a slightly cleaned up version "b", please review. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-25T22:34:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95710 <pre>Mike Matrigali created DERBY-5785: ------------------------------------- Summary: investigate improving identity column performance by reusing nested transaction Key: DERBY-5785 URL: https://issues.apache.org/jira/browse/DERBY-5785 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Reporter: Mike Matrigali Priority: Minor Currently every insert of row with an identity column creates a nested user transaction to update the value in syscolumns, and then destroys it. It seems like this transaction could be cached in the user context and then reused. I believe this is what is done for the nested read only transaction that is used for compiling statements. The change may improve performance and also lead to less objects being created/destroyed per insert. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Mike Matrigali (JIRA 2012-05-25T16:44:22 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95707 <pre>[Auto-generated mail] *Daily* 1342306/2012-05-24 18:00:08 MEST Failed Tests OK Skip Duration Suite ------------------------------------------------------- *Jvm: 1.7* lin 0 15840 15840 0 .% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 .% derbyall 0 2 2 0 .% compatibility 0 2 2 0 .% demoSuite sol 0 15840 15840 0 .% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 .% derbyall 0 2 2 0 .% compatibility 0 2 2 0 .% demoSuite sol32 0 15840 15840 0 .% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 .% derbyall 0 2 2 0 .% compatibility 0 2 2 0 .% demoSuite vista-64 0 15831 15831 0 .% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 .% derbyall NA NA NA NA compatibility 0 2 2 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-1342306.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/1342306_bySig.html *Jvm: 1.6* lin 0 15735 15735 0 1639.91% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 37.79% derbyall 0 2 2 0 110.94% compatibility 0 2 2 0 .% demoSuite sles 0 15735 15735 0 1028.77% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 1 166 165 0 36.33% derbyall 0 2 2 0 67.38% compatibility 0 2 2 0 .% demoSuite sol 0 15723 15723 0 1181.15% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 29.51% derbyall 0 2 2 0 69.16% compatibility 0 2 2 0 .% demoSuite sol32 0 15723 15723 0 86.33% suitesAll 0 15 15 0 53.84% jdbcapiAutoLoad 0 14 14 0 58.33% JDBCDriversAll 0 15 15 0 46.15% JDBCDriversClient 0 14 14 0 16.66% JDBCDriversEmbedded 0 166 166 0 1114.15% derbyall 0 2 2 0 14750.00% compatibility 0 2 2 0 700.00% demoSuite solN+1 0 15723 15723 0 239.42% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 45.72% derbyall 0 2 2 0 76.79% compatibility 0 2 2 0 .% demoSuite sparc 0 15723 15723 0 592.31% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 23.14% derbyall 0 2 2 0 72.76% compatibility 0 2 2 0 .% demoSuite vista 0 15724 15724 0 203.84% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 44.45% derbyall NA NA NA NA compatibility 0 2 2 0 .% demoSuite vista-64 0 15724 15724 0 292.27% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 44.50% derbyall NA NA NA NA compatibility 0 2 2 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1342306.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/1342306_bySig.html *Jvm: 1.5* lin 0 167 167 0 37.63% derbyall 0 13755 13755 0 2878.89% suitesAll sles 0 167 167 0 35.46% derbyall 0 13755 13755 0 1731.86% suitesAll sol 0 167 167 0 32.23% derbyall 0 13743 13743 0 2232.32% suitesAll sol32 0 167 167 0 1177.46% derbyall 0 13743 13743 0 103.41% suitesAll solN+1 0 167 167 0 41.86% derbyall 0 13743 13743 0 2423.84% suitesAll sparc 0 167 167 0 23.43% derbyall 0 13743 13743 0 1413.84% suitesAll vista 0 167 167 0 34.54% derbyall 0 13744 13744 0 1447.11% suitesAll vista-64 0 167 167 0 44.35% derbyall 0 13744 13744 0 332.50% suitesAll Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-1342306.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/FailReports/1342306_bySig.html *Jvm: phoneME* ubuntu 0 7034 7034 0 .% suitesAll Details in http://dbtg.foundry.sun.com/derby/test/Daily/javaME/testing/Limited/testSummary-1342306.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/javaME/FailReports/1342306_bySig.html ------------------------------------------------------- Changes in http://dbtg.foundry.sun.com/derby/test/Daily/UpdateInfo/1342306.txt ( All results in http://dbtg.foundry.sun.com/derby/test/ ) </pre> Ole.Solberg-veTT2BtV2gBXrIkS9f7CXA< at >public.gmane.org 2012-05-25T15:55:25 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95704 <pre>Rick Hillegas created DERBY-5784: ------------------------------------ Summary: Setting a parameter as NUMERIC fails to match stored value, but setting the parameter as untyped does match Key: DERBY-5784 URL: https://issues.apache.org/jira/browse/DERBY-5784 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.10.0.0 Reporter: Rick Hillegas I will attach a repro. The behavior should be the same according to table B-4 in the JDBC spec. Lance Andersen reports that other databases find the row using both setObject() overloads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Rick Hillegas (JIRA 2012-05-25T14:42:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95693 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13283338#comment-13283338 ] Dag H. Wanvik commented on DERBY-118: ------------------------------------- Regressions showed no problems, building tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-25T12:28:24 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95690 <pre>Knut Anders Hatlen created DERBY-5783: ----------------------------------------- Summary: Remove duplicated code for starting remote processes in replication tests Key: DERBY-5783 URL: https://issues.apache.org/jira/browse/DERBY-5783 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.10.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor ReplicationRun has two copies of each of the methods runUserCommand(), runUserCommandRemotely() and processOutput(). One variant takes an id parameter (used only in debug output), and one doesn't. It would be sufficient to have one copy of each of these methods. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Knut Anders Hatlen (JIRA 2012-05-25T11:54:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95688 <pre> [ https://issues.apache.org/jira/browse/DERBY-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen resolved DERBY-3371. --------------------------------------- Resolution: Fixed Fix Version/s: 10.10.0.0 Issue &amp; fix info: (was: Patch Available) Committed revision 1342566. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Knut Anders Hatlen (JIRA 2012-05-25T10:46:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95687 <pre> [ https://issues.apache.org/jira/browse/DERBY-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13283288#comment-13283288 ] Knut Anders Hatlen commented on DERBY-2601: ------------------------------------------- One note about client/server compatibility. If, for example, a transaction-severity error happens on the server, the server sees an exception whose getErrorCode() method returns 30000. Here's what getErrorCode() on the client-side exception will return for the various combinations of new and old servers and clients: (old server, old client) -&gt; -1 (old server, new client) -&gt; 0 (new server, old client) -&gt; -30001 (new server, new client) -&gt; 30000 ("old" means any version without the fix, "new" means any version with the fix) With an old server and a new client, 0 is returned because the old servers always send SQLCODE -1, and the client converts that to an error code by adding one and changing the sign. Since 0 matches ExceptionSeverity.NO_APPLICABLE_SEVERITY (intended for "when the system was unable to determine the severity"), I think it's slightly less wrong than -1. But if someone thinks returning -1, as we did before, is better, and that it's worthwhile adding logic to handle that, it should be possible to change it. With a new server and an old client, the server will send an SQLCODE that encodes the original error code, but the client doesn't know how to transform that back to an error code, and will return the SQLCODE unchanged (-30001). Again, it should be possible to make the server send SQLCODE -1 when it's talking to an old client. However, since we don't document the error codes, and since -30001 is no more or less correct than -1 (they're both wrong), I'm not sure if it's worth adding special handling of this case. Maybe a release note? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Knut Anders Hatlen (JIRA 2012-05-25T10:26:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95686 <pre> [ https://issues.apache.org/jira/browse/DERBY-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2601: -------------------------------------- Attachment: d2601-1a.diff Attaching d2601-1a.diff which makes the server send error codes to the client. Derbyall, suites.All and the compatibility test passed with the patch. In the current code, when an exception happens on the server, the server always sends an SQLCARD with SQLCODE=-1, and this value is used as error code when the client generates the SQLException. Simply changing the server to send the actual error code in the SQLCODE field wouldn't work, though, since the client uses the sign of the SQLCODE to tell whether the condition is a warning or an error. Positive values are interpreted as warnings, and negative as errors. The client doesn't depend on the negative value being -1, so we could send any negative value to tell that an error occurred. The patch exploits this by encoding the always non-negative error code seen on the server as a negative value in the SQL code: sqlCode = -errorCode - 1 When the client generates an SQLException, it can convert the SQL code back to the original error code: errorCode = -sqlCode - 1 More detailed description of the changes: * drda/org/apache/derby/impl/drda/DRDAConnThread.java - Push down some of the logic that determines the SQLCODE from writeSQLCAGRP() to getSqlCode(). - Make getSqlCode() return the error code encoded in a negative integer if the exception represents an error. - Remove unused severity parameter in writeSQLCARD(). * client/org/apache/derby/client/am/Sqlca.java - Added getErrorCode() method to convert SQL code to error code. - Promote STATEMENT_SEVERITY errors to TRANSACTION_SEVERITY errors if the connection is in auto-commit mode. This is needed in order to match the error codes returned by the embedded driver in auto-commit (see TransactionResourceImpl.handleException() for the corresponding code in the engine). (This does not happen automatically otherwise because the server-side connection is never auto-commit, even if the client-side connection is.) - getUnformattedMessage() now shows the error code instead of the SQL code. * client/org/apache/derby/client/am/SqlException.java - If the exception is generated from an SQLCA, use getErrorCode() instead of getSqlCode() to initialize the error code. * client/org/apache/derby/client/am/SQLExceptionFactory40.java - Check for error code only if the sub-class of SQLException cannot be determined from the SQL state. (I don't know why the original code checked the error code in the first place. The embedded driver only looks at the SQL state.) Now that the error code is something else than -1, the early checks for error code for example made syntax errors that happened in auto-commit mode (whose error codes match TRANSACTION_SEVERITY) would be returned as SQLTransactionRollbackExceptions instead of SQLSyntaxErrorExceptions. * testing/org/apache/derbyTesting/functionTests/master/testclientij.out - Update master to expect the correct error codes. * testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java - Added helper method that checks the error code. * testing/org/apache/derbyTesting/functionTests/tests/derbynet/BadConnectionTest.java - Expect the correct error code. * testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/J2EEDataSourceTest.java - Use new helper method to check error codes. * testing/org/apache/derbyTesting/functionTests/tests/lang/ErrorCodeTest.java - Enable for client/server. * testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java * testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ShutdownMaster.java * testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ShutdownSlave.java - Expect correct error codes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Knut Anders Hatlen (JIRA 2012-05-25T10:20:23 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95678 <pre>Rick Hillegas created DERBY-5782: ------------------------------------ Summary: Consider lifting the limit on the number of columns which can appear in a SELECT list Key: DERBY-5782 URL: https://issues.apache.org/jira/browse/DERBY-5782 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.10.0.0 Reporter: Rick Hillegas Derby SELECT lists are limited to 1012 columns, the value of Limits.DB2_MAX_ELEMENTS_IN_SELECT_LIST. This limit is not found in the SQL Standard. We should consider lifting it based on user demand: http://old.nabble.com/limit-on-the-number-of-columns-to33901308.html#a33901308 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Rick Hillegas (JIRA 2012-05-24T16:05:28 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95677 <pre>Rick Hillegas created DERBY-5781: ------------------------------------ Summary: Investigate lifting the limit on the number of columns in a Derby table Key: DERBY-5781 URL: https://issues.apache.org/jira/browse/DERBY-5781 Project: Derby Issue Type: Improvement Components: SQL Reporter: Rick Hillegas Fix For: 10.10.0.0 Derby tables are limited to 1012 columns. This arbitrary limit is not found in the SQL Standard and is the value of Limits.DB2_MAX_ELEMENTS_IN_SELECT_LIST. We should investigate lifting this limit based on user demand: http://old.nabble.com/limit-on-the-number-of-columns-to33901308.html#a33901308 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Rick Hillegas (JIRA 2012-05-24T15:59:28 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95676 <pre>[Auto-generated mail] *Daily* 1341921/2012-05-23 18:00:08 MEST Failed Tests OK Skip Duration Suite ------------------------------------------------------- *Jvm: 1.7* lin 0 15840 15840 0 .% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 .% derbyall 0 2 2 0 .% compatibility 0 2 2 0 .% demoSuite sol 0 15840 15840 0 .% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 .% derbyall 0 2 2 0 .% compatibility 0 2 2 0 .% demoSuite sol32 0 15840 15840 0 .% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 .% derbyall 0 2 2 0 .% compatibility 0 2 2 0 .% demoSuite vista-64 0 15831 15831 0 .% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 .% derbyall NA NA NA NA compatibility 0 2 2 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-1341921.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/1341921_bySig.html *Jvm: 1.6* lin 0 15735 15735 0 1699.33% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 38.21% derbyall 0 2 2 0 157.17% compatibility 0 2 2 0 .% demoSuite sles 0 15735 15735 0 1064.03% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 35.29% derbyall 0 2 2 0 65.89% compatibility 0 2 2 0 .% demoSuite sol 0 15723 15723 0 1177.10% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 29.24% derbyall 0 2 2 0 68.72% compatibility 0 2 2 0 .% demoSuite sol32 0 15723 15723 0 86.42% suitesAll 0 15 15 0 46.15% jdbcapiAutoLoad 0 14 14 0 50.00% JDBCDriversAll 0 15 15 0 53.84% JDBCDriversClient 0 14 14 0 16.66% JDBCDriversEmbedded 0 166 166 0 1089.62% derbyall 0 2 2 0 14600.00% compatibility 0 2 2 0 750.00% demoSuite solN+1 0 15723 15723 0 238.64% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 45.48% derbyall 0 2 2 0 76.37% compatibility 0 2 2 0 .% demoSuite sparc 0 15723 15723 0 594.24% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 23.11% derbyall 0 2 2 0 73.13% compatibility 0 2 2 0 .% demoSuite vista 0 15724 15724 0 204.18% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 45.12% derbyall NA NA NA NA compatibility 0 2 2 0 .% demoSuite vista-64 0 15724 15724 0 292.70% suitesAll 0 15 15 0 .% jdbcapiAutoLoad 0 14 14 0 .% JDBCDriversAll 0 15 15 0 .% JDBCDriversClient 0 14 14 0 .% JDBCDriversEmbedded 0 166 166 0 44.46% derbyall NA NA NA NA compatibility 0 2 2 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1341921.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/1341921_bySig.html *Jvm: 1.5* lin 0 167 167 0 37.59% derbyall 0 13755 13755 0 2855.32% suitesAll sles 0 167 167 0 34.83% derbyall 0 13755 13755 0 1762.10% suitesAll sol 0 167 167 0 32.87% derbyall 0 13743 13743 0 2238.95% suitesAll sol32 0 167 167 0 1170.42% derbyall 0 13743 13743 0 103.27% suitesAll solN+1 0 167 167 0 41.84% derbyall 0 13743 13743 0 2429.70% suitesAll sparc 0 167 167 0 23.55% derbyall 0 13743 13743 0 1404.61% suitesAll vista 0 167 167 0 34.16% derbyall 0 13744 13744 0 1451.14% suitesAll vista-64 0 167 167 0 45.07% derbyall 0 13744 13744 0 333.31% suitesAll Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-1341921.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/FailReports/1341921_bySig.html *Jvm: phoneME* ubuntu 0 7034 7034 0 .% suitesAll Details in http://dbtg.foundry.sun.com/derby/test/Daily/javaME/testing/Limited/testSummary-1341921.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/javaME/FailReports/1341921_bySig.html ------------------------------------------------------- Changes in http://dbtg.foundry.sun.com/derby/test/Daily/UpdateInfo/1341921.txt ( All results in http://dbtg.foundry.sun.com/derby/test/ ) </pre> Ole.Solberg-veTT2BtV2gBXrIkS9f7CXA< at >public.gmane.org 2012-05-24T15:55:22 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95675 <pre> [ https://issues.apache.org/jira/browse/DERBY-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen reassigned DERBY-2601: ----------------------------------------- Assignee: Knut Anders Hatlen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Knut Anders Hatlen (JIRA 2012-05-24T13:30:56 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95674 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13282025#comment-13282025 ] Dag H. Wanvik edited comment on DERBY-118 at 5/23/12 11:12 PM: --------------------------------------------------------------- Looking at the standard, I see that the default value is defined as &lt;default option&gt; ::= &lt;literal&gt; | &lt;datetime value function&gt; | USER | CURRENT_USER | CURRENT_ROLE | SESSION_USER | SYSTEM_USER | CURRENT_PATH | &lt;implicitly typed value specification&gt; This would seem to preclude a cast in the form of CHAR(CURRENT_DATE), but this would be ok: CREATE TABLE ok (create_date_string VARCHAR(40) DEFAULT CURRENT_DATE) and similarly for CURRENT_TIME and CURRENT_TIMESTAMP - it doesn't currently. We do allow this implicit coercion on INSERT. Uploading a proof-of-concept patch which makes the above table creation work: derby-118.diff. No tests yet, running regressions. was (Author: dagw): Looking at the standard, I see that the default value is defined as &lt;default option&gt; ::= &lt;literal&gt; | &lt;datetime value function&gt; | USER | CURRENT_USER | CURRENT_ROLE | SESSION_USER | SYSTEM_USER | CURRENT_PATH | &lt;implicitly typed value specification&gt; This would seem to preclude a cast in the form of CHAR(CURRENT_DATE), but this would be ok: CREATE TABLE ok (create_date_string VARCHAR(40) DEFAULT CURRENT_DATE) and similarly for CURRENT_TIME and CURRENT_TIMESTAMP. We do allow this implicit coercion on INSERT. Uploading a proof-of-concept patch which makes the above table creation work: derby-118.diff. No tests yet, running regressions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-23T23:13:40 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95673 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik reassigned DERBY-118: ----------------------------------- Assignee: Dag H. Wanvik -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-23T23:13:40 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95672 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13282025#comment-13282025 ] Dag H. Wanvik commented on DERBY-118: ------------------------------------- Looking at the standard, I see that the default value is defined as &lt;default option&gt; ::= &lt;literal&gt; | &lt;datetime value function&gt; | USER | CURRENT_USER | CURRENT_ROLE | SESSION_USER | SYSTEM_USER | CURRENT_PATH | &lt;implicitly typed value specification&gt; This would seem to preclude a cast in the form of CHAR(CURRENT_DATE), but this would be ok: CREATE TABLE ok (create_date_string VARCHAR(40) DEFAULT CURRENT_DATE) and similarly for CURRENT_TIME and CURRENT_TIMESTAMP. We do allow this implicit coercion on INSERT. Uploading a proof-of-concept patch which makes the above table creation work: derby-118.diff. No tests yet, running regressions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-23T23:11:41 http://comments.gmane.org/gmane.comp.apache.db.derby.devel/95671 <pre> [ https://issues.apache.org/jira/browse/DERBY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-118: -------------------------------- Attachment: derby-118.stat derby-118.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Dag H. Wanvik (JIRA 2012-05-23T23:11:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.apache.db.derby.devel