[jira] Commented: (DERBY-3149) Add ant targets for building and running the package private tests against the classes directories
[ https://issues.apache.org/jira/browse/DERBY-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555851#action_12555851 ] Kristian Waagan commented on DERBY-3149: Regarding why junit-pptesting isn't adding junit.jar automatically, I'm not quite sure. I experimented a little bit, but it seems that with my ant version (1.6.5) adding the jar in the target isn't enough. Even if I add tools/java/junit.jar to the classpath for target junit-pptesting I'm not able to run it without already having told ant where to find it (I currently have a junit.jar in ~/.ant/lib). I think ant needs junit.jar to initialize the junit task. I know this area is a bit tricky with ant, and they also have a FAQ-entry for it: http://ant.apache.org/faq.html#delegating-classloader-1.6 Maybe ant 1.7 solves the problem for us, but we only require 1.6.3 (or higher) to build Derby. It would be nice if someone knowing ant well could help find the best way to do this. Add ant targets for building and running the package private tests against the classes directories -- Key: DERBY-3149 URL: https://issues.apache.org/jira/browse/DERBY-3149 Project: Derby Issue Type: Sub-task Components: Build tools, Test Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3149-1a.diff, derby-3149-1a.stat, derby-3149-1b.diff, derby-3149-2a-conditional_compilation_fix.diff, derby-3149-2b-conditional_compilation_fix.diff Create ant targets in build.xml to compile and run the package private tests. The first step will be to run the tests against the classes directories. Implementing a solution that runs against jars is not technically difficult, it just brings a host of decisions to be taken... Maybe even more important, does running against the jars add any value? The compile will be included in the 'all' target to test the implementation. Feel free to post your concerns if you think building the package private tests should be a manual action only. The tests will also be run as part of junit-all / junitreport. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3149) Add ant targets for building and running the package private tests against the classes directories
[ https://issues.apache.org/jira/browse/DERBY-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555876#action_12555876 ] Kristian Waagan commented on DERBY-3149: Is there already a variable for Java SE 5.0 compile classpath in the build script(s)? If not, are there any plans to introduce one? I see there is a java15compile.classpath in the root build.xml, but as far as I can tell, it is only set when using the new autoprop feature and I haven't found any targets using it yet. I see that many targets are using compile.classpath. This is currently set to java14compile.classpath, and changing it would probably be a bad idea. Last, I see that we require J2SE 5.0 or higher in BUILDING.txt. Don't we need a variable for this default compile classpath? In my case I'm using J2SE 5.0 features in some tests, and I would like these tests to be built when JDK 1.5 is available. Currently they are only built if JDK 1.6 is available. Add ant targets for building and running the package private tests against the classes directories -- Key: DERBY-3149 URL: https://issues.apache.org/jira/browse/DERBY-3149 Project: Derby Issue Type: Sub-task Components: Build tools, Test Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3149-1a.diff, derby-3149-1a.stat, derby-3149-1b.diff, derby-3149-2a-conditional_compilation_fix.diff, derby-3149-2b-conditional_compilation_fix.diff Create ant targets in build.xml to compile and run the package private tests. The first step will be to run the tests against the classes directories. Implementing a solution that runs against jars is not technically difficult, it just brings a host of decisions to be taken... Maybe even more important, does running against the jars add any value? The compile will be included in the 'all' target to test the implementation. Feel free to post your concerns if you think building the package private tests should be a manual action only. The tests will also be run as part of junit-all / junitreport. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
[ https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3037: -- Derby Info: (was: [Patch Available]) Removing 'patch available' since the issue only has one patch which appears to have been committed (and merged to 10.3). Language ResultSet.finish() is called even when the ResultSet is going to be re-used. - Key: DERBY-3037 URL: https://issues.apache.org/jira/browse/DERBY-3037 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Assignee: Mamta A. Satoor Fix For: 10.3.2.2, 10.4.0.0 Attachments: Derby_3037_AlterTableConstantActionChanges_v1_diff.txt, Derby_3037_AlterTableConstantActionChanges_v1_stat.txt DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to be the lifetime of the activation, but did not fix up the correct calls to ResultSet.close() and ResultSet.finish(). A language ResultSet's lifetime should be driven by the activation, so activation.close() should call finish() on its ResultSet. EmbedResultSet should call close on its language ResultSet (theResults field) when the JDBC ResultSet is closed, it should not be calling finish() on its ResultSet. See comments in DERBY-827 for some more details and issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3298) Getting Started manual needs clearer introduction to connection URL
[ https://issues.apache.org/jira/browse/DERBY-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555885#action_12555885 ] Dyre Tjeldvoll commented on DERBY-3298: --- Patch applies cleanly, and the recent messages on derby-user show that this is an important change. I plan to commit it shortly. Getting Started manual needs clearer introduction to connection URL --- Key: DERBY-3298 URL: https://issues.apache.org/jira/browse/DERBY-3298 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.2.1 Reporter: Kim Haase Assignee: Kim Haase Priority: Minor Attachments: DERBY-3298.diff, DERBY-3298.zip A user pointed out that the placeholder databaseURL is used on p. 17 of the Getting Started Guide PDF without any context. The URL concept is mentioned briefly several pages before, on p. 14, but is not fully introduced until p. 21. Terminology should be more consistent, and some cross-references are needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3221) java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
[ https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555896#action_12555896 ] Dyre Tjeldvoll commented on DERBY-3221: --- Could this be another followup error from DERBY-827? Seems like the problem COULD be that SortResultSet.sortTemplateRow is not reset/recomputed when SortResultSet is closed (nothing is done to it in SortResultSet.close()). It seems like the sanity check which compares sortTemplateRow to the row being fed to the sorter fails, which I guess could happen if the template left over from the previous execution doesn't match the new one. I'll try out the repro and see if the theory holds. java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0 Key: DERBY-3221 URL: https://issues.apache.org/jira/browse/DERBY-3221 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4, 10.3.2.1 Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0) Reporter: Tim Halloran Attachments: conlomerate.tar.gz We are getting an SQLException when several prepared statement deletes are done upon an existing database. As far as we can tell this exception should never occur unless (evil) things like deleting the database or editing files occurs. This is using the embedded driver within a plug-in inside RAD 7.0 (and Eclipse 3.3). I'm not sure what else to submit that might be helpful. java.sql.SQLException: The conglomerate (-5) requested does not exist. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(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.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown Source) at $Proxy1.execute(Unknown Source) at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source) at com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown Source) at com.surelogic.sierra.jdbc.project.ClientProjectManager.synchronizeProject(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.synchronize(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.run(Unknown Source) at org.eclipse.core.internal.jobs.Worker.run(Unknown Source) Caused by: ERROR XSAI2: The conglomerate (-5) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRow(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.IndexSetChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.RowChangerImpl.finish(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 14 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-2872) Add Replication functionality to Derby
[ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555939#action_12555939 ] Kim Haase commented on DERBY-2872: -- Thank you so much, Jørgen, for the quick and very clear replies. That should keep me going! 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] 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=12555938#action_12555938 ] Jørgen Løland commented on DERBY-2872: -- Hi Kim, I'll try to sort out the ambiguities in the func spec: 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? In the first implementation of replication, the master database must be booted (also implies created) before startMaster is specified. This may be improved in Derby 10.5. 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. Just to be clear - you can replicate a database that's been around for a long time. 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.) Looking at Connection URL Attributes in the reference manual, the replication attributes can be combined with 'user' and 'password' only. Username and password attributes are required if authentication/authorization is turned on. The replication attributes start*, stop* and failover can not be used at the same time, whereas slavehost/slaveport can be used in combination with these as specified in the funcspec. 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. I can see why you would assume this, but it is not correct. I will update the funcspec soon to clearify this. The answer: No, you have to run startSlave on the slave host in addition to startMaster on the master host. Regarding lost connection: there are no commands to fix a lost connection between the master and slave. The replication functionality will try to reestablish the connection internally (no user interaction), but may eventually have to give up. If replication is stopped because of a lost connection (or any other reason, like issuing a stopMaster command), replication must be started over again from scratch. Another question: at several points the spec says that the slave redoes the transaction log sent by the master. What does that mean exactly? Does it perform the operations that are recorded in the transaction log? Correct - the slave applies the operations found in the log. Once again, thanks for documenting replication! 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
Regression Test Report - Daily 608562 - Sun DBTG
[Auto-generated mail] *Daily* 608562/2008-01-03 18:00:12 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0272272 071.81% derbyall 01014610146 0 1167.73% suitesAll linN+1 0272272 098.54% derbyall 01014610146 0 111.29% suitesAll sles 0272272 070.76% derbyall 01014610146 0 809.67% suitesAll sol 0272272 075.50% derbyall 01014610146 0 1347.07% suitesAll solN+1 0272272 096.04% derbyall 01014610146 0 172.66% suitesAll sparc 0272272 065.66% derbyall 01014610146 0 356.17% suitesAll vista 0272272 093.30% derbyall 091249124 065.95% suitesAll w2003 0272272 094.91% derbyall 091249124 0 129.61% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-608562.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/608562_bySig.html *Jvm: 1.5* lin 0273273 071.14% derbyall F:2,E:084308428 0 880.79% suitesAll linN+1 0273273 0 .% derbyall 084308430 0 .% suitesAll sles 0273273 070.24% derbyall 084308430 0 567.31% suitesAll sol 0273273 079.53% derbyall 084308430 0 850.60% suitesAll solN+1 0273273 087.93% derbyall 084308430 0 787.72% suitesAll sparc 0273273 065.97% derbyall 084308430 0 690.59% suitesAll vista 0273273 071.60% derbyall 074087408 0 401.92% suitesAll w2003 0273273 073.76% derbyall 074087408 0 257.74% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-608562.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/608562_bySig.html *Jvm: 1.4* lin 0270270 272.41% derbyall 083788378 0 800.49% suitesAll linN+1 0270270 2 .% derbyall 083788378 0 .% suitesAll sles 0270270 270.11% derbyall 083788378 0 527.57% suitesAll sol 0270270 277.53% derbyall 083788378 0 674.76% suitesAll solN+1 0270270 288.25% derbyall 083788378 0 742.47% suitesAll sparc 0270270 266.71% derbyall 083788378 0 706.37% suitesAll vista 0270270 2 .% derbyall 073567356 0 391.28% suitesAll w2003 0270270 2 .% derbyall 073577357 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-608562.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/608562_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/608562.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-3221) java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
[ https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555967#action_12555967 ] Dyre Tjeldvoll commented on DERBY-3221: --- Looking more closely at the repro, I see that all columns are of type BIGINT. So it seems reasonable that the sort template has type SQLLongint, but why is it given a row where the 3rd (the failure is is reported for the third (colid=2) column) column has type SQLInteger? java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0 Key: DERBY-3221 URL: https://issues.apache.org/jira/browse/DERBY-3221 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4, 10.3.2.1 Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0) Reporter: Tim Halloran Attachments: conlomerate.tar.gz We are getting an SQLException when several prepared statement deletes are done upon an existing database. As far as we can tell this exception should never occur unless (evil) things like deleting the database or editing files occurs. This is using the embedded driver within a plug-in inside RAD 7.0 (and Eclipse 3.3). I'm not sure what else to submit that might be helpful. java.sql.SQLException: The conglomerate (-5) requested does not exist. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(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.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown Source) at $Proxy1.execute(Unknown Source) at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source) at com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown Source) at com.surelogic.sierra.jdbc.project.ClientProjectManager.synchronizeProject(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.synchronize(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.run(Unknown Source) at org.eclipse.core.internal.jobs.Worker.run(Unknown Source) Caused by: ERROR XSAI2: The conglomerate (-5) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRow(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.IndexSetChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.RowChangerImpl.finish(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 14 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (12 issues) Subscriber: derby-dev Key Summary DERBY-3298 Getting Started manual needs clearer introduction to connection URL https://issues.apache.org/jira/browse/DERBY-3298 DERBY-2359 Code cleanups for the org.apache.derby.impl.store.access.* packages https://issues.apache.org/jira/browse/DERBY-2359 DERBY-3294 Convert demo/checkToursDB.java to junit https://issues.apache.org/jira/browse/DERBY-3294 DERBY-3254 Implement the replication failover functionality https://issues.apache.org/jira/browse/DERBY-3254 DERBY-3088 convert to junit, or otherwise eliminate version in tests which require an update of the master in the release management process https://issues.apache.org/jira/browse/DERBY-3088 DERBY-3189 Replication: Add connection url command options for starting and stopping master https://issues.apache.org/jira/browse/DERBY-3189 DERBY-3205 Replication: Add connection url command options for starting and stopping slave https://issues.apache.org/jira/browse/DERBY-3205 DERBY-3117 Adjust master build script to require the Java 5 compiler to build Derby https://issues.apache.org/jira/browse/DERBY-3117 DERBY-3023 Different result rows depending on the sequence of INNER JOIN and OUTER JOIN https://issues.apache.org/jira/browse/DERBY-3023 DERBY-2953 Dump the information about rollbacks of the global transaction (introduced in DERBY-2220 and DERBY-2432) to derby.log https://issues.apache.org/jira/browse/DERBY-2953 DERBY-3083 Network server demands a file called derbynet.jar in classpath https://issues.apache.org/jira/browse/DERBY-3083 DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
[jira] Commented: (DERBY-3221) java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
[ https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555945#action_12555945 ] Dyre Tjeldvoll commented on DERBY-3221: --- My theory does NOT hold :( The failure still happens when sortTemplateRow is re-initialized in each call to openCore. Could this be a conversion thing? That is; should it be possible to promote an SQLInteger to an SQLLongint? If I read the code correctly, it seems like col2 is the sort template (SQLLongint) and col1 is from the current row. Also, where does the last NPE come from? Is that just a consequence, or is it significant? java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0 Key: DERBY-3221 URL: https://issues.apache.org/jira/browse/DERBY-3221 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4, 10.3.2.1 Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0) Reporter: Tim Halloran Attachments: conlomerate.tar.gz We are getting an SQLException when several prepared statement deletes are done upon an existing database. As far as we can tell this exception should never occur unless (evil) things like deleting the database or editing files occurs. This is using the embedded driver within a plug-in inside RAD 7.0 (and Eclipse 3.3). I'm not sure what else to submit that might be helpful. java.sql.SQLException: The conglomerate (-5) requested does not exist. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(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.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown Source) at $Proxy1.execute(Unknown Source) at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source) at com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown Source) at com.surelogic.sierra.jdbc.project.ClientProjectManager.synchronizeProject(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.synchronize(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.run(Unknown Source) at org.eclipse.core.internal.jobs.Worker.run(Unknown Source) Caused by: ERROR XSAI2: The conglomerate (-5) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRow(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.IndexSetChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.RowChangerImpl.finish(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 14 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-3221) java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
[ https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555977#action_12555977 ] Bryan Pendleton commented on DERBY-3221: Hi Dyre, thanks for looking at this! You might find it useful to capture the generated code and decompile it, then look at that together with a close look at the query plan. Presumably the sort is due to a GROUP BY or ORDER BY clause in the query, or perhaps due to a DISTINCT? When I was looking at some datatype mismatch problems in ORDER BY processing (DERBY-2352), I saw that the code generation logic for these areas involves objects like the ResultColumn and the OrderByList. Hopefully this is helpful, let me know and I can try to offer some more ideas. java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0 Key: DERBY-3221 URL: https://issues.apache.org/jira/browse/DERBY-3221 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4, 10.3.2.1 Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0) Reporter: Tim Halloran Attachments: conlomerate.tar.gz We are getting an SQLException when several prepared statement deletes are done upon an existing database. As far as we can tell this exception should never occur unless (evil) things like deleting the database or editing files occurs. This is using the embedded driver within a plug-in inside RAD 7.0 (and Eclipse 3.3). I'm not sure what else to submit that might be helpful. java.sql.SQLException: The conglomerate (-5) requested does not exist. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(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.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown Source) at $Proxy1.execute(Unknown Source) at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source) at com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown Source) at com.surelogic.sierra.jdbc.project.ClientProjectManager.synchronizeProject(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.synchronize(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.run(Unknown Source) at org.eclipse.core.internal.jobs.Worker.run(Unknown Source) Caused by: ERROR XSAI2: The conglomerate (-5) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRow(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.IndexSetChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.RowChangerImpl.finish(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 14 more -- 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.1.3.1 Reproduced also on 10.1.3.1. There is a slight difference in behavior (of a similar query) that I will have to check into, and update this report. 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.1.3.1, 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] Issue Comment Edited: (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=12556033#action_12556033 ] clr edited comment on DERBY-3301 at 1/4/08 11:43 AM: --- There is a similar query that sometimes returns the expected result and sometimes returns a single row. The difference in the query is that there is an extra clause in the WHERE clause: AND UNBOUND_P.NAME = 'orange' This query is expected to return three rows PERSONID |PROJID --- 3 |1 2 |1 1 |1 3 rows selected but sometimes only one row is returned PERSONID |PROJID --- 1 |1 1 rows selected was (Author: clr): There is a similar query that sometimes returns the expected result and sometimes returns a single row. The difference in the query is that there is an extra clause in the WHERE clause: AND UNBOUND_P.NAME = 'orange' This query is expected to return three rows PERSONID |PROJID --- 3 |1 2 |1 1 |1 3 rows selected but sometimes only one row is returned PERSONID |PROJID --- 1 |1 3 rows selected 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.1.3.1, 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
[jira] Resolved: (DERBY-2063) derbynet/ShutDownDBWhenNSShutsDownTest.junit fails with IBM JVM 142 and 15 on Linux platform
[ https://issues.apache.org/jira/browse/DERBY-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner resolved DERBY-2063. -- Resolution: Cannot Reproduce derbynet/ShutDownDBWhenNSShutsDownTest.junit fails with IBM JVM 142 and 15 on Linux platform Key: DERBY-2063 URL: https://issues.apache.org/jira/browse/DERBY-2063 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.1.4 Reporter: Manjula Kutty Assignee: Daniel John Debrunner *** Start: ShutDownDBWhenNSShutsDownTest jdk1.5.0 DerbyNetClient derbynetmats:derbynetmats 2006-11-07 23:29:20 *** 0 add .F. There was 1 failure: 1) testEngineShutdownDoesNotTakeDownNS(org.apache.derbyTesting.functionTests.tests.derbynet.ShutDownDBWhenNSShutsDownTest)junit.framework.ComparisonFailure: Engine shutdown expected:XJ015 but was:08001 FAILURES!!! Tests run: 2, Failures: 1, Errors: 0 Test Failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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=12556033#action_12556033 ] Craig Russell commented on DERBY-3301: -- There is a similar query that sometimes returns the expected result and sometimes returns a single row. The difference in the query is that there is an extra clause in the WHERE clause: AND UNBOUND_P.NAME = 'orange' This query is expected to return three rows PERSONID |PROJID --- 3 |1 2 |1 1 |1 3 rows selected but sometimes only one row is returned PERSONID |PROJID --- 1 |1 3 rows selected 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.1.3.1, 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] Updated: (DERBY-3294) Convert demo/checkToursDB.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjula Kutty updated DERBY-3294: - Attachment: DERBY_3294_diff_1_4.txt DERBY_3294_stat_1_4.txt Thanks for the comments, John, Here is my reply and the new patch. Please review. - 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 would like to keep like that now and will change once I figure out how to do it. - 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(). Done! - 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.) -The doSelect() asserts with the original number of rows. But after deleting the rows, those asserts will fail. So I thought not doing since the assertions will make sure the rows are deleted. - testToursDB() method's Javadoc specifies a wrong exception in the @throws tag. There is also a typo (tourdb -- ToursDB) in the Javadoc. Fixed - tearDown() lacks @throws tag in Javadoc. Fixed 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_diff_1_4.txt, DERBY_3294_stat_01_02.txt, DERBY_3294_stat_1_4.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.
