[jira] Assigned: (DERBY-1903) Convert largedata/LobLimits.java to junit
[ https://issues.apache.org/jira/browse/DERBY-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-1903: -- Assignee: (was: V.Narayanan) I am not actively working on this issue and hence am unassigning myself Convert largedata/LobLimits.java to junit -- Key: DERBY-1903 URL: https://issues.apache.org/jira/browse/DERBY-1903 Project: Derby Issue Type: Sub-task Components: Test Reporter: V.Narayanan Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-1336) isWrapper for method can be moved into EmbedStatement class this would enable removal of implementations in EmbedStatement40,EmbedCallableStatement40 and EmbedPreparedSta
[ https://issues.apache.org/jira/browse/DERBY-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-1336: -- Assignee: (was: V.Narayanan) I am not actively working on this issue and hence am unassigning myself isWrapper for method can be moved into EmbedStatement class this would enable removal of implementations in EmbedStatement40,EmbedCallableStatement40 and EmbedPreparedStatement40 -- Key: DERBY-1336 URL: https://issues.apache.org/jira/browse/DERBY-1336 Project: Derby Issue Type: Improvement Components: JDBC Reporter: V.Narayanan Priority: Minor Attachments: MoveIsWrapperFor.diff, MoveIsWrapperFor.stat The signature of the isWrapperFor method is boolean isWrapperFor(Class? iface) throws SQLException this can be changed to boolean isWrapperFor(Class iface) throws SQLException and can be moved into EmbedStatement This will enable us to remove the implementations from EmbedCallableStatement40,EmbedPreparedStatement40 and EmbedStatement40 thanx Narayanan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3064) Implement the LogShipper that will enable the shipping of Log records from the master to the slave
[ https://issues.apache.org/jira/browse/DERBY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan closed DERBY-3064. -- Implement the LogShipper that will enable the shipping of Log records from the master to the slave -- Key: DERBY-3064 URL: https://issues.apache.org/jira/browse/DERBY-3064 Project: Derby Issue Type: Sub-task Components: Miscellaneous Reporter: V.Narayanan Assignee: V.Narayanan Attachments: LogShipperImpl_v1.diff, LogShipperImpl_v1.stat, LogShipperImpl_v2.diff, LogShipperImpl_v2.stat, LogShipperImpl_v3.diff, LogShipperImpl_v3.stat, LogShipperImpl_v4.diff, LogShipperImpl_v4.stat, LogShipperImpl_v5.diff, LogShipperImpl_v5.stat, LogShipperIntegration_v1.diff, LogShipperIntegration_v1.stat, LogShipperIntegration_v2.diff, LogShipperIntegration_v2.stat, LogShipperIntegration_v3.diff, LogShipperIntegration_v3.stat, LogShipperIntegration_v4.diff, LogShipperIntegration_v4.stat, LogShipperIntegration_v5.diff, LogShipperIntegration_v5.stat, LogShipperIntegration_v6.diff, LogShipperIntegration_v6.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3064) Implement the LogShipper that will enable the shipping of Log records from the master to the slave
[ https://issues.apache.org/jira/browse/DERBY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan resolved DERBY-3064. Resolution: Fixed All the patches for this issue have been committed Implement the LogShipper that will enable the shipping of Log records from the master to the slave -- Key: DERBY-3064 URL: https://issues.apache.org/jira/browse/DERBY-3064 Project: Derby Issue Type: Sub-task Components: Miscellaneous Reporter: V.Narayanan Assignee: V.Narayanan Attachments: LogShipperImpl_v1.diff, LogShipperImpl_v1.stat, LogShipperImpl_v2.diff, LogShipperImpl_v2.stat, LogShipperImpl_v3.diff, LogShipperImpl_v3.stat, LogShipperImpl_v4.diff, LogShipperImpl_v4.stat, LogShipperImpl_v5.diff, LogShipperImpl_v5.stat, LogShipperIntegration_v1.diff, LogShipperIntegration_v1.stat, LogShipperIntegration_v2.diff, LogShipperIntegration_v2.stat, LogShipperIntegration_v3.diff, LogShipperIntegration_v3.stat, LogShipperIntegration_v4.diff, LogShipperIntegration_v4.stat, LogShipperIntegration_v5.diff, LogShipperIntegration_v5.stat, LogShipperIntegration_v6.diff, LogShipperIntegration_v6.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3235) Implement the replication stop functionality
[ https://issues.apache.org/jira/browse/DERBY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan closed DERBY-3235. -- Implement the replication stop functionality Key: DERBY-3235 URL: https://issues.apache.org/jira/browse/DERBY-3235 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: StopImplementation_v1.diff, StopImplementation_v1.stat, StopImplementation_v1_NotForCommit.diff, StopImplementation_v1_NotForCommit.stat, StopImplementation_v2.diff, StopImplementation_v2.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3235) Implement the replication stop functionality
[ https://issues.apache.org/jira/browse/DERBY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan resolved DERBY-3235. Resolution: Fixed All the patches for this issue have been committed. Implement the replication stop functionality Key: DERBY-3235 URL: https://issues.apache.org/jira/browse/DERBY-3235 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: StopImplementation_v1.diff, StopImplementation_v1.stat, StopImplementation_v1_NotForCommit.diff, StopImplementation_v1_NotForCommit.stat, StopImplementation_v2.diff, StopImplementation_v2.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-1028) Change constructors in NetConnection classes to use LogWriter instead of NetLogWriter
[ https://issues.apache.org/jira/browse/DERBY-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-1028: -- Assignee: (was: V.Narayanan) I am not actively working on this issue and hence am unassigning myself. Change constructors in NetConnection classes to use LogWriter instead of NetLogWriter - Key: DERBY-1028 URL: https://issues.apache.org/jira/browse/DERBY-1028 Project: Derby Issue Type: Improvement Components: JDBC Reporter: V.Narayanan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3131) Background cleaner has no daemon service after database creation
[ https://issues.apache.org/jira/browse/DERBY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-3131. - Background cleaner has no daemon service after database creation Key: DERBY-3131 URL: https://issues.apache.org/jira/browse/DERBY-3131 Project: Derby Issue Type: Bug Components: Services, Store Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.4.0.0 Attachments: d3131.diff, d3131.stat When a database is booted, the page cache and the container cache are given a daemon service to perform operations in the background. This happens in BaseDataFileFactory.postRecovery(). When a new database is created this code is not executed (presumably because we don't perform recovery), so its background cleaner remains inactive until the database is rebooted. The background cleaner should be active after the first boot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3280) Poor distribution of hash values from RecordId.hashCode()
[ https://issues.apache.org/jira/browse/DERBY-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-3280. - Poor distribution of hash values from RecordId.hashCode() - Key: DERBY-3280 URL: https://issues.apache.org/jira/browse/DERBY-3280 Project: Derby Issue Type: Improvement Components: Performance, Services, Store Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.4.0.0 Attachments: d3280.diff, TestClient.java The hash values returned by RecordId.hashCode() are constructed by performing bitwise xor on the 32 least significant bits of the record number, the page number, the container id and the segment id. Since all of these values tend to be relatively small positive integers, the hash values also tend to be clustered in a very small range. This leads to a higher frequency of hash collisions in the lock table, which makes the hash tables work less efficiently and thereby reduces the performance. As an example, the simple join load in the test client attached to DERBY-1961 uses two tables, TENKTUP and ONEKTUP, with 1 rows and 1000 rows, respectively. The RecordIds for these 11000 rows map to less than 900 distinct hash codes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3142) sysinfo ignores derby.ui.locale
[ https://issues.apache.org/jira/browse/DERBY-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-3142. - sysinfo ignores derby.ui.locale --- Key: DERBY-3142 URL: https://issues.apache.org/jira/browse/DERBY-3142 Project: Derby Issue Type: Bug Components: Localization, Tools Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.3.2.1, 10.4.0.0 Attachments: d3142-1.diff, d3142-2.diff, d3142-2a.diff, d3142-with-test.diff, d3142-with-test.stat Sysinfo messages are localized using the system's default locale instead of the locale specified by derby.ui.locale. Example: $ java -Dderby.ui.locale=de_DE -jar derbyrun.jar sysinfo|head -- Java Information -- Java Version:1.6.0_01 Java Vendor: Sun Microsystems Inc. Java home: /usr/jdk/instances/jdk1.6.0/jre Java classpath: derbyrun.jar OS name: SunOS OS architecture: x86 OS version: 5.11 Java user name: kah Java user home: /home/kah Setting the default locale works correctly: $ LC_ALL=de_DE.UTF-8 java -jar derbyrun.jar sysinfo|head -- Java-Informationen -- Java-Version: 1.6.0_01 Java-Anbieter: Sun Microsystems Inc. Java-Home: /usr/jdk/instances/jdk1.6.0/jre Java-Klassenpfad: derbyrun.jar Name des Betriebssystems: SunOS Architektur des Betriebssystems: x86 Betriebssystemversion: 5.11 Java-Benutzername: kah Java-Benutzerausgangsverzeichnis: /home/kah -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3175) NullPointerException on INSERT after ALTER TABLE ... DROP COLUMN
[ https://issues.apache.org/jira/browse/DERBY-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-3175. - NullPointerException on INSERT after ALTER TABLE ... DROP COLUMN Key: DERBY-3175 URL: https://issues.apache.org/jira/browse/DERBY-3175 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Bryan Pendleton Fix For: 10.3.2.1, 10.4.0.0 Attachments: bug.sql, d3175_codeChangeOnly.diff, fixWith3177Case.diff, fixWithTest.diff, merge10_3.diff, preserveAutoincValue.diff, preserveFixWithComments.diff ij version 10.3 ij connect 'jdbc:derby:bugdb;create=true'; ij create table t ( x varchar(12), y varchar(12), id int primary key generated by default as identity ); 0 rows inserted/updated/deleted ij alter table t drop column y; 0 rows inserted/updated/deleted ij insert into t(x) values 'a'; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) at org.apache.derby.iapi.tools.run.main(Unknown Source) Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: java.lang.NullPointerException at org.apache.derby.impl.sql.compile.ResultColumn.columnTypeAndLengthMatch(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.columnTypesAndLengthsMatch(Unknown Source) at org.apache.derby.impl.sql.compile.InsertNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) ... 11 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3254) Implement the replication failover functionality
[ https://issues.apache.org/jira/browse/DERBY-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1221#action_1221 ] Øystein Grøvlen commented on DERBY-3254: Thanks for the patch, Narayanan. My main question about this patch is about failure handling during failover. If failover is not successful, I think the current master should continue as master. Also, I am not sure that just being able to send the failover message is sufficient to decide that failover was successful. Maybe some acknowledgement from the slave is needed? As it is, the implementation of stop and failover is identical at the slave. I guess it is the implementation of stop that is missing something? Some minor issues: - LogToFile#stopReplicationSlaveRole(): I think the javadoc here is a bit inaccurate. AFAIU, setting the inReplicationSlaveMode flag will make the slave complete recovery and boot the database. - There is a double ; in SlaveController#failover. - I think a successful failover should also be recorded in derby.log also at the (former) slave. - There is a typo in the message text for R011: perfomed Implement the replication failover functionality Key: DERBY-3254 URL: https://issues.apache.org/jira/browse/DERBY-3254 Project: Derby Issue Type: Sub-task Components: Replication Reporter: V.Narayanan Assignee: V.Narayanan Attachments: failover_impl_notforcommit.diff, failover_impl_notforcommit.stat, failover_impl_v1.diff, failover_impl_v1.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3235) Implement the replication stop functionality
[ https://issues.apache.org/jira/browse/DERBY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1222#action_1222 ] Øystein Grøvlen commented on DERBY-3235: It seems to me that there are still pieces that are missing from the implementation of stop replication. I cannot find any code that interrupts the ongoing booting of the database at the slave. When the patch for failover (DERBY-3254) is committed, executing stop will cause the slave to complete its booting and be able to start serving clients. I guess that is not the intention. Implement the replication stop functionality Key: DERBY-3235 URL: https://issues.apache.org/jira/browse/DERBY-3235 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: StopImplementation_v1.diff, StopImplementation_v1.stat, StopImplementation_v1_NotForCommit.diff, StopImplementation_v1_NotForCommit.stat, StopImplementation_v2.diff, StopImplementation_v2.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Øystein Grøvlen updated DERBY-3184: --- Derby Info: (was: [Patch Available]) Patch, derby-3184-bugfix-1a.diff, looks good. I took the liberty of correcting the message text a bit before committing the patch as revision 608419. Replication: Connection attempts to a database in slave mode must fail -- Key: DERBY-3184 URL: https://issues.apache.org/jira/browse/DERBY-3184 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.stat When a database 'X' is booted in slave mode, the call to Monitor.startPersistentService(X,...) will not complete because the call gets stuck in LogToFile#recover. This is intentional. For as long as startPersistentService is blocked, however, other threads that try to connect to 'X' (effectively calling Monitor.findService(X, ...)) will also hang. This is unacceptable, and needs to raise an error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1231#action_1231 ] Jørgen Løland commented on DERBY-3184: -- No problem. Thanks for reviewing and committing :) Replication: Connection attempts to a database in slave mode must fail -- Key: DERBY-3184 URL: https://issues.apache.org/jira/browse/DERBY-3184 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.stat When a database 'X' is booted in slave mode, the call to Monitor.startPersistentService(X,...) will not complete because the call gets stuck in LogToFile#recover. This is intentional. For as long as startPersistentService is blocked, however, other threads that try to connect to 'X' (effectively calling Monitor.findService(X, ...)) will also hang. This is unacceptable, and needs to raise an error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles
[ https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1245#action_1245 ] Dag H. Wanvik commented on DERBY-2207: -- Yes, that's how I read it too. It is not implemented yet; not sure how to do it, lcc (LanguageConnectionContext) is shared between root and nested connections, but seemed the natural place for holding current role. The authorization stack that the standard prescribes would need to be implemented somehow. Btw, it would seem we need this for running with definer's right (stored procedures) as well? (if we want to allow that in future, I see vol 13, section 4.10 says its implementation defined.) Is setting isolation level currently persistent beyond a nested connection? Improve usability of Derby's client/server security by implementing ANSI Roles -- Key: DERBY-2207 URL: https://issues.apache.org/jira/browse/DERBY-2207 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Attachments: spec.html, spec.html, spec.html, spec.html, spec.html Implementing ANSI Roles will make it easier to manage security for multi-user applications with high user turnover. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles
[ https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1250#action_1250 ] Dag H. Wanvik commented on DERBY-2207: -- Is setting isolation level currently persistent beyond a nested connection? Tried this, and the answer is yes. Improve usability of Derby's client/server security by implementing ANSI Roles -- Key: DERBY-2207 URL: https://issues.apache.org/jira/browse/DERBY-2207 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Attachments: spec.html, spec.html, spec.html, spec.html, spec.html Implementing ANSI Roles will make it easier to manage security for multi-user applications with high user turnover. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3294) Convert demo/checkToursDB.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1272#action_1272 ] John H. Embretsen commented on DERBY-3294: -- Thanks for the update. Some follow-up comments, having considered the second patch: - I think it may be possible to implement the doDelete(), doUpdate() and doSelect() methods as independent fixtures (by utilizing rollback(), setUp()/tearDown() and possibly a new test setup class) or to specify a specific ordering of fixtures in the suite() method, but the current scheme works quite well, so keeping it is ok with me. - I think it is confusing to have both the methods insertMaps() and InsertMaps(). One suggestion is to comply with common Java naming conventions and use a lowercase letter in the beginning of method names, for example by renaming InsertMaps() to insertMapsPrivileged(). - the non-JUnit version of this test tests that select count(*) works (not sure of the intended purpose of doing this) from all the tables both before and after deletes/updates, while the new version only selects before doUpdate()/doDelete(). Is that intentional? (I'm not saying it should be different, I just think the reasoning behind this decision should be on record.) - testToursDB() method's Javadoc specifies a wrong exception in the @throws tag. There is also a typo (tourdb -- ToursDB) in the Javadoc. - tearDown() lacks @throws tag in Javadoc. Convert demo/checkToursDB.java to junit --- Key: DERBY-3294 URL: https://issues.apache.org/jira/browse/DERBY-3294 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.4.0.0 Reporter: Manjula Kutty Assignee: Manjula Kutty Priority: Minor Fix For: 10.4.0.0 Attachments: DERBY-3294_diff_12_28.txt, DERBY-3294_stat_12_28.txt, DERBY_3294_diff_01_02.txt, DERBY_3294_stat_01_02.txt Place holder for the junit conversion of demo/checkToursDB.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2359) Code cleanups for the org.apache.derby.impl.store.access.* packages
[ https://issues.apache.org/jira/browse/DERBY-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2359: --- Fix Version/s: 10.4.0.0 Code cleanups for the org.apache.derby.impl.store.access.* packages --- Key: DERBY-2359 URL: https://issues.apache.org/jira/browse/DERBY-2359 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.3.1.4 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: btreeforwardscan_cleanup.diff, derby-2359-1a-unused_imports.diff, derby-2359-1a-unused_imports.stat, derby-2359-1b-unused_imports.diff, derby-2359-1b-unused_imports.stat, derby-2359-2a_method-renames.diff, derby-2359-2a_method-renames.stat, derby-2359-3a-visibility_changes.diff, derby-2359-3a-visibility_changes.stat, derby-2359-4a-OpenConglomerateScratchSpace.diff, derby-2359-5a-Conglomerate_API_change.diff When trying to learn more about the access layer, it was discovered that some code improvements could easily be made to increase the readability of the code. Patches attached to this issue will be cleanup patches only, and no functionality should be changed. Changes the will/may be made: * remove unused imports * remove unused methods * fix JavaDoc errors * tighter encapsulation and removal of unused variables where appropriate -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2359) Code cleanups for the org.apache.derby.impl.store.access.* packages
[ https://issues.apache.org/jira/browse/DERBY-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2359: --- Derby Info: [Patch Available] Code cleanups for the org.apache.derby.impl.store.access.* packages --- Key: DERBY-2359 URL: https://issues.apache.org/jira/browse/DERBY-2359 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.3.1.4 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: btreeforwardscan_cleanup.diff, derby-2359-1a-unused_imports.diff, derby-2359-1a-unused_imports.stat, derby-2359-1b-unused_imports.diff, derby-2359-1b-unused_imports.stat, derby-2359-2a_method-renames.diff, derby-2359-2a_method-renames.stat, derby-2359-3a-visibility_changes.diff, derby-2359-3a-visibility_changes.stat, derby-2359-4a-OpenConglomerateScratchSpace.diff, derby-2359-5a-Conglomerate_API_change.diff When trying to learn more about the access layer, it was discovered that some code improvements could easily be made to increase the readability of the code. Patches attached to this issue will be cleanup patches only, and no functionality should be changed. Changes the will/may be made: * remove unused imports * remove unused methods * fix JavaDoc errors * tighter encapsulation and removal of unused variables where appropriate -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2359) Code cleanups for the org.apache.derby.impl.store.access.* packages
[ https://issues.apache.org/jira/browse/DERBY-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2359: --- Attachment: derby-2359-5a-Conglomerate_API_change.diff derby-2359-4a-OpenConglomerateScratchSpace.diff I committed two changes to trunk with revision 608466, which removed a self-assignment and an unused locale variable. 'derby-2359-4a-OpenConglomerateScratchSpace.diff' contains a few cleanups (unused method and variable, some JavaDoc). 'derby-2359-5a-Conglomerate_API_change.diff' removes the unused argument 'conglomId' from the Conglomerate interface. I've run tests for both patches, and I saw no related failures. Code cleanups for the org.apache.derby.impl.store.access.* packages --- Key: DERBY-2359 URL: https://issues.apache.org/jira/browse/DERBY-2359 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.3.1.4 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: btreeforwardscan_cleanup.diff, derby-2359-1a-unused_imports.diff, derby-2359-1a-unused_imports.stat, derby-2359-1b-unused_imports.diff, derby-2359-1b-unused_imports.stat, derby-2359-2a_method-renames.diff, derby-2359-2a_method-renames.stat, derby-2359-3a-visibility_changes.diff, derby-2359-3a-visibility_changes.stat, derby-2359-4a-OpenConglomerateScratchSpace.diff, derby-2359-5a-Conglomerate_API_change.diff When trying to learn more about the access layer, it was discovered that some code improvements could easily be made to increase the readability of the code. Patches attached to this issue will be cleanup patches only, and no functionality should be changed. Changes the will/may be made: * remove unused imports * remove unused methods * fix JavaDoc errors * tighter encapsulation and removal of unused variables where appropriate -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - Daily 608147 - Sun DBTG
[Auto-generated mail] *Daily* 608147/2008-01-02 18:00:13 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0272272 071.86% derbyall 01014610146 0 1338.91% suitesAll linN+1 0272272 098.01% derbyall 01014610146 0 113.89% suitesAll sles 0272272 071.11% derbyall 01014610146 0 823.61% suitesAll sol 0272272 075.76% derbyall 01014610146 0 1530.99% suitesAll solN+1 0272272 096.61% derbyall 01014610146 0 167.62% suitesAll sparc 0272272 065.42% derbyall F:0,E:11014610145 0 354.02% suitesAll vista 0272272 093.92% derbyall 091249124 066.26% suitesAll w2003 0272272 095.27% derbyall 091249124 0 129.85% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-608147.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/608147_bySig.html *Jvm: 1.5* lin 0273273 071.23% derbyall 084308430 0 875.85% suitesAll linN+1 0273273 0 .% derbyall 084308430 0 .% suitesAll sles 0273273 070.56% derbyall 084308430 0 565.47% suitesAll sol 0273273 079.53% derbyall 084308430 0 842.57% suitesAll solN+1 0273273 087.86% derbyall 084308430 0 788.84% suitesAll sparc 0273273 066.00% derbyall 084308430 0 696.49% suitesAll vista 0273273 071.64% derbyall 074087408 0 395.51% suitesAll w2003 0273273 073.71% derbyall 074087408 0 257.39% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-608147.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/608147_bySig.html *Jvm: 1.4* lin 0270270 272.57% derbyall 083788378 0 791.31% suitesAll linN+1 0270270 2 .% derbyall 083788378 0 .% suitesAll sles 0270270 270.42% derbyall 083788378 0 532.72% suitesAll sol 0270270 277.26% derbyall 083788378 0 676.78% suitesAll solN+1 0270270 288.44% derbyall 083788378 0 734.63% suitesAll sparc 0270270 266.75% derbyall 083788378 0 700.24% suitesAll vista 0270270 2 .% derbyall 073567356 0 394.75% suitesAll w2003 0270270 2 .% derbyall 073577357 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-608147.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/608147_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/608147.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555613#action_12555613 ] Kim Haase commented on DERBY-3169: -- Thanks a lot for the functional spec, Jorgen. It is so well written and organized that it will be fairly easy to adapt for the documentation. As suggested in the spec, the documentation will be in two different manuals: Admin Guide: Conceptual overview and descriptions of tasks (in Part Two, Derby Administration Guide, after Backing up and restoring databases Reference Manual: Writeups on connection URL attributes used as replication commands: startMaster stopMaster startSlave stopSlave failover Add documentation for replication - Key: DERBY-3169 URL: https://issues.apache.org/jira/browse/DERBY-3169 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Kim Haase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2872) Add Replication functionality to Derby
[ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555632#action_12555632 ] Kim Haase commented on DERBY-2872: -- I have a question about the startMaster attribute. Can it can be used *when* a database is created (that is, in conjunction with the create=true attribute), or must it be used *after* the database has been created? The spec (v8) is not absolutely clear on this, because it says both a master database must be created before it can be replicated. and ...replication does not need to be specified when the database is created; it can be initiated at any time after the database is created. The first part of the second sentence implies that replication *could* be started when the database is created -- that is, in conjunction with create=true. But maybe it means only that you don't have to start it *immediately* after creating the database -- you can replicate a database that's been around for a long time. One of the sections in the reference topics on connection attributes is Combining with other attributes, so it would be helpful to have this information -- and any other information you have on which attribute combinations are allowed and which are not. For example, I'm sure you can combine these with the username and password attributes, and I'm sure you can't specify two of the replication commands at the same time. About others, I'm not certain.) Add Replication functionality to Derby -- Key: DERBY-2872 URL: https://issues.apache.org/jira/browse/DERBY-2872 Project: Derby Issue Type: New Feature Components: Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: master_classes_1.pdf, poc_master_v2.diff, poc_master_v2.stat, poc_master_v2b.diff, poc_slave_v2.diff, poc_slave_v2.stat, poc_slave_v2b.diff, poc_slave_v2c.diff, proof-of-concept_v2b-howto.txt, proof_of_concept_master.diff, proof_of_concept_master.stat, proof_of_concept_slave.diff, proof_of_concept_slave.stat, replication_funcspec.html, replication_funcspec_v2.html, replication_funcspec_v3.html, replication_funcspec_v4.html, replication_funcspec_v5.html, replication_funcspec_v6.html, replication_funcspec_v7.html, replication_funcspec_v8.html, replication_script.txt, slave_classes_1.pdf It would be nice to have replication functionality to Derby; many potential Derby users seem to want this. The attached functional specification lists some initial thoughts for how this feature may work. Dag Wanvik had a look at this functionality some months ago. He wrote a proof of concept patch that enables replication by copying (using file system copy) and redoing the existing Derby transaction log to the slave (unfortunately, I can not find the mail thread now). DERBY-2852 contains a patch that enables replication by sending dedicated logical log records to the slave through a network connection and redoing these. Replication has been requested and discussed previously in multiple threads, including these: http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/[EMAIL PROTECTED] http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3301) Incorrect result from query with nested EXIST
Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Reporter: Craig Russell Fix For: 10.2.1.6 Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE |WEEKLYHOURS |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR |SALARY |WAGE |DISCRIMINATOR - 1 |emp1First |emp1Last |emp1Middle |1970-06-09 21:00:00.0 |NULL |NULL |NULL
[jira] Commented: (DERBY-2872) Add Replication functionality to Derby
[ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555645#action_12555645 ] Kim Haase commented on DERBY-2872: -- Sorry, something else in the spec is not quite clear to me. Is it correct that to start replication, all you need to do is specify the startMaster/slavehost/[slaveport] attributes on the master database? It appears from the description that this command gets things going on both the master and the slave without your having to explicitly run startSlave on the slave system. It appears that something like this happens when you stop the master, so I'm assuming it happens when you start it too. If that is the case, what is the startSlave attribute used for? Is it only used if the slave-to-master connection is lost? But in that case, according to the Failure Scenarios section, the slave automatically tries to reestablish the connection, unless I've misunderstood. Thanks for any clarifications. Add Replication functionality to Derby -- Key: DERBY-2872 URL: https://issues.apache.org/jira/browse/DERBY-2872 Project: Derby Issue Type: New Feature Components: Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: master_classes_1.pdf, poc_master_v2.diff, poc_master_v2.stat, poc_master_v2b.diff, poc_slave_v2.diff, poc_slave_v2.stat, poc_slave_v2b.diff, poc_slave_v2c.diff, proof-of-concept_v2b-howto.txt, proof_of_concept_master.diff, proof_of_concept_master.stat, proof_of_concept_slave.diff, proof_of_concept_slave.stat, replication_funcspec.html, replication_funcspec_v2.html, replication_funcspec_v3.html, replication_funcspec_v4.html, replication_funcspec_v5.html, replication_funcspec_v6.html, replication_funcspec_v7.html, replication_funcspec_v8.html, replication_script.txt, slave_classes_1.pdf It would be nice to have replication functionality to Derby; many potential Derby users seem to want this. The attached functional specification lists some initial thoughts for how this feature may work. Dag Wanvik had a look at this functionality some months ago. He wrote a proof of concept patch that enables replication by copying (using file system copy) and redoing the existing Derby transaction log to the slave (unfortunately, I can not find the mail thread now). DERBY-2852 contains a patch that enables replication by sending dedicated logical log records to the slave through a network connection and redoing these. Replication has been requested and discussed previously in multiple threads, including these: http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/[EMAIL PROTECTED] http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated DERBY-3301: - Affects Version/s: 10.2.1.6 10.3.2.1 Fix Version/s: (was: 10.2.1.6) I just tried this with 10.3.2.1 and the same error occurs. I changed the fix version from 10.2.1.6 to unknown (oops). Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE |WEEKLYHOURS |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR |SALARY |WAGE |DISCRIMINATOR
[jira] Commented: (DERBY-2254) Assert during log file switch: log file position exceeded max log file size
[ https://issues.apache.org/jira/browse/DERBY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555737#action_12555737 ] quartz commented on DERBY-2254: --- A few details: -I have this state generated from a linux machine (not OS specific). -I use the derbynet NetworkServerControl, not the embeded driver. -I also saw the error while starting up on windows with embeded driver over the copied DB. -I am on 10.2.2.0. I deleted the log file and the DB works. Of course I expect data loss but I wanted to know that only the log file seems affected. Assert during log file switch: log file position exceeded max log file size --- Key: DERBY-2254 URL: https://issues.apache.org/jira/browse/DERBY-2254 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.1.4 Environment: Solaris 10, Java SE 6 build 104 Reporter: Olav Sandstaa When running simple tpc-b like transactions against a embedded Derby based on a SANE build of trunk the following assertion occurs for the background thread and all user threads: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size This seems to occur during a switch to a new log file. derby.log contains the following call stack for the background thread: Exception trace: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540) at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357) at org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439) at org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416) at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) at org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) at org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) at java.lang.Thread.run(Thread.java:619) 2007-01-17 23:09:48.638 GMT Thread[derby.rawStoreDaemon,5,derby.daemons] Cleanup action starting org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540) at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357) at org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439) at org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416) at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) at org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) at org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) at java.lang.Thread.run(Thread.java:619) Cleanup action completed For my user threads the call stack is similar: Database Class Loader started - derby.database.classpath='' 2007-01-17 23:09:36.401 GMT Thread[Thread-51,5,main] (XID = 12632406), (SESSIONID = 51), (DATABASE = /export/home/tmp/derby-db), (DRDAID = null), Cleanup action starting 2007-01-17 23:09:36.401 GMT Thread[Thread-51,5,main] (XID = 12632406), (SESSIONID = 51), (DATABASE = /export/home/tmp/derby-db), (DRDAID = null), Failed Statement is: UPDATE accounts SET abal = abal + ? WHERE aid = ? AND bid = ? org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555739#action_12555739 ] A B commented on DERBY-3301: Any chance you could a) post a fully reproducing script or Java program, and/or b) try it out with the 10.1.3.1 release? I'm wondering if this might be the same underlying issue as DERBY-3288--if it is, then it should work with 10.1.3.1. Trying it out there might help determine when the problem was introduced...(esp. is it a regression?) Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE |WEEKLYHOURS |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR |SALARY |WAGE |DISCRIMINATOR
[jira] Commented: (DERBY-1068) change of store contract: online compress operations should not share any locks with user transactions
[
https://issues.apache.org/jira/browse/DERBY-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555742#action_12555742
]
quartz commented on DERBY-1068:
---
I have had a serious problem with SYSCS_UTIL.SYSCS_COMPRESS_TABLE.
On separate connections and separate yet concurrent threads (obviously)
I try to pack my table while insert are ongoing, basically like this:
call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'SAMPLE_PERIOD_TB', 1);
INSERT INTO sample_period_tb (start_time,end_time) VALUES
(119203740,119203770);
The exception I get is this:
A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Lock : ROW, SYSCONGLOMERATES, (4,20)
Waiting XID : {21215745, S} , APP, INSERT INTO sample_period_tb
(start_time,end_time) VALUES (119203740,119203770)
Granted XID : {18280645, S}
Lock : ROW, SYSCONGLOMERATES, (4,19)
Waiting XID : {18280645, X} , APP, alter table APP.SAMPLE_PERIOD_TB
compress sequential
Granted XID : {18280645, S} , {21215759, S} , {21215745, S}
. The selected victim is XID : 21215745.
This is horrible! I would have to stop all inserts or what?
If this improvement mean the problem would go away, let us know (and make it
high priority!).
Otherwise, you may want to file a new bug!
change of store contract: online compress operations should not share any
locks with user transactions
--
Key: DERBY-1068
URL: https://issues.apache.org/jira/browse/DERBY-1068
Project: Derby
Issue Type: Improvement
Components: Store
Reporter: Andreas Korneliussen
Assignee: Mike Matrigali
Priority: Minor
Propose to add the following to the store contract:
* truncate and compress requires exclusive table locking
* the truncate, purge and compress operations do not share any locks with
user transactions
Currently the store implementation allows users to share locks in truncate
and possibly purge.
This request is driven by:
http://www.nabble.com/conflict-detection-strategies-t1120376.html#a2938142
and:
http://www.nabble.com/RowLocation-contract-from-storage-engine-t1142235.html#a2994156
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Regression Test Report - tinderbox_trunk16 608645 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 608645/2008-01-03 22:52:33 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 0272272 085.73% derbyall F:1,E:01015110150 0 1170.70% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-608645.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/608645_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/608645.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Updated: (DERBY-3288) wrong query result in presence of a unique index
[ https://issues.apache.org/jira/browse/DERBY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A B updated DERBY-3288: --- Attachment: d3288_incomplete_v1.patch DERBY-3288.htm Regression occurs as of svn # 423754, for DERBY-1357. Attaching DERBY-3288.html with some background information and a description of the problem, along with a possible solution. Also attaching a quick patch to implement the solution mentioned in DERBY-3288.html. The patch is called d3288_incomplete_v1.patch. It is incomplete for two reasons: 1) I have not yet added an appropriate test case to the regression suites. 2) There was one failure in derbyall when I ran with this change (SpaceTable.sql). I still need to investigate the failure to see what might be going wrong. suites.All ran cleanly. Not sure when I'll have time to follow-up, but I will post when I know more... wrong query result in presence of a unique index Key: DERBY-3288 URL: https://issues.apache.org/jira/browse/DERBY-3288 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Gerald Khin Attachments: d3288_incomplete_v1.patch, DERBY-3288.htm The DDL to reproduce the bug is: CREATE TABLE tab_a (PId BIGINT NOT NULL); CREATE TABLE tab_c (Id BIGINT NOT NULL PRIMARY KEY, PAId BIGINT NOT NULL, PBId BIGINT NOT NULL); INSERT INTO tab_c VALUES (91, 81, 82); INSERT INTO tab_c VALUES (92, 81, 84); INSERT INTO tab_c VALUES (93, 81, 88); INSERT INTO tab_c VALUES (96, 81, 83); CREATE TABLE tab_v (OId BIGINT NOT NULL , UGId BIGINT NOT NULL, val CHAR(1) NOT NULL); CREATE UNIQUE INDEX tab_v_i1 ON tab_v (OId, UGId, val); CREATE INDEX tab_v_i2 ON tab_v (UGId, val, OId); INSERT INTO tab_v VALUES (81, 31, 'A'); INSERT INTO tab_v VALUES (82, 31, 'A'); INSERT INTO tab_v VALUES (83, 31, 'A'); INSERT INTO tab_v VALUES (84, 31, 'A'); INSERT INTO tab_v VALUES (85, 31, 'A'); INSERT INTO tab_v VALUES (86, 31, 'A'); INSERT INTO tab_v VALUES (87, 31, 'A'); INSERT INTO tab_v VALUES (81, 32, 'A'); INSERT INTO tab_v VALUES (82, 32, 'A'); INSERT INTO tab_v VALUES (83, 32, 'A'); INSERT INTO tab_v VALUES (84, 32, 'A'); INSERT INTO tab_v VALUES (85, 32, 'A'); INSERT INTO tab_v VALUES (86, 32, 'A'); INSERT INTO tab_v VALUES (87, 32, 'A'); CREATE TABLE tab_b (Id BIGINT NOT NULL PRIMARY KEY, OId BIGINT NOT NULL); INSERT INTO tab_b VALUES (141, 81); INSERT INTO tab_b VALUES (142, 82); INSERT INTO tab_b VALUES (143, 84); INSERT INTO tab_b VALUES (144, 88); INSERT INTO tab_b VALUES (151, 81); INSERT INTO tab_b VALUES (152, 83); CREATE TABLE tab_d (Id BIGINT NOT NULL PRIMARY KEY, PAId BIGINT NOT NULL, PBId BIGINT NOT NULL); INSERT INTO tab_d VALUES (181, 141, 142); INSERT INTO tab_d VALUES (182, 141, 143); INSERT INTO tab_d VALUES (186, 151, 152); The query returning the wrong result is: SELECT tab_b.Id FROM tab_b JOIN tab_c ON (tab_b.OId = tab_c.PAId OR tab_b.OId = tab_c.PBId) LEFT OUTER JOIN tab_a ON tab_b.OId = PId WHERE EXISTS (SELECT 'X' FROM tab_d WHERE (PAId = 141 AND PBId = tab_b.Id) OR (PBId = 141 AND PAId = tab_b.Id)) AND EXISTS (SELECT 'X' FROM tab_v WHERE OId = tab_b.OId AND UGId = 31 AND val = 'A') The result should consist of two rows (142),(143), but it returns only one row (142). The correct result would be returned if the index tab_v_i1 had been created as non-unique. The correct result would also be returned if the condition ...AND val='A' had been replaced by ...AND val='A' || ''. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - tinderbox_trunk16 608701 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 608701/2008-01-04 02:22:19 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 0272272 086.19% derbyall F:1,E:01015110150 0 1189.93% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-608701.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/608701_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/608701.txt ( All results in http://dbtg.thresher.com/derby/test/ )
