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/95721 <pre>[Auto-generated mail] *Daily* 1342706/2012-05-25 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</pre> Ole.Solberg-veTT2BtV2gBXrIkS9f7CXA< at >public.gmane.org 2012-05-26T15:55:22 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 JIR</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</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:</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</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 a</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</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): Looki</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 cont</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