[jira] Commented: (DERBY-3273) convert derbynet/testconnection.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551718 ] Ole Solberg commented on DERBY-3273: Looks like the 604074 checkin was incomplete: old test still referenced in derbynetmats and j9derbynetmats: ./org/apache/derbyTesting/functionTests/suites/derbynetmats.runall:10:derbynet/testconnection.java ./org/apache/derbyTesting/functionTests/suites/j9derbynetmats.runall:6:derbynet/testconnection.java See http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/604075-derbyall_diff.txt > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/derbyTesting/functionTests/tests/derbynet/testconnection > convert derbynet/testconnection.java to junit > - > > Key: DERBY-3273 > URL: https://issues.apache.org/jira/browse/DERBY-3273 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3273_diff.txt, derby-3273_diff2.txt > > > convert derbynet/testconnection.java to junit. -- 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 604075 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 604075/2007-12-14 02:22:29 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 2274272 086.24% derbyall 01013410134 0 1175.97% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-604075.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/604075_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/604075.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Updated: (DERBY-3253) NullPointer Exception (NPE) from query with IN predicate containing two values and joining a view with a large table. ERROR 38000: The exception 'java.lang.NullPointerExc
[
https://issues.apache.org/jira/browse/DERBY-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-3253:
---
Attachment: d3253_v1.patch
A surprisingly simple repro of this NPE can be created as follows:
create table t1 (i int, vc varchar(10));
insert into t1 values (1, 'one'), (2, 'two'), (3, 'three'), (1, 'un');
select * from t1, (select * from t1) x
where t1.i = x.i and x.vc in ('un', 'trois');
The key here is that the IN list's left operand points to a column from the
subselect, X.VC. As part of DERBY-47, the IN list will be changed into a
BinaryRelationalOperatorNode of the form "X.VC = ?", and that node, which we
call a "probe predicate", will serve to represent the IN list operator
throughout the various phases of optimization.
That said, as part of preprocessing Derby will look at the query and realize
that the sub-select can be flattened. When flattening the subquery, any
references to the subquery's RCL will be remapped to point to the underlying
expression. That means the left operand of the probe predicate "X.VC = ?" will
be changed to point directly to column "VC" of table T1. The code where this
happens is in the "flatten" method of FromSubquery:
/* Remap all ColumnReferences from the outer query to this node.
* (We replace those ColumnReferences with clones of the matching
* expression in the SELECT's RCL.
*/
rcl.remapColumnReferencesToExpressions();
outerPList.remapColumnReferencesToExpressions();
For the example query above, outerPList holds the two predicates "T1.I = X.I"
and "X.VC = ?", so we will attempt to remap the column references in those two
predicates. That brings us to the remapColumnReferencesToExpressions() method
of BinaryOperatorNode, where we have:
public ValueNode remapColumnReferencesToExpressions()
throws StandardException
{
leftOperand = leftOperand.remapColumnReferencesToExpressions();
rightOperand = rightOperand.remapColumnReferencesToExpressions();
return this;
}
Notice how the leftOperand can change here--and in the above query, it *will*
change to point directly to T1 instead of indirectly to the subquery. So now
the probe predicate's left operand is different from the left operand of the
original InListOperatorNode that the probe predicate replaced. That in it
itself is fine, but it causes problems later.
Namely, when it comes time to generate the final tree for the query, we realize
that the probe predicate is not "useful" for probing because it references
"VC", which is the second column in table T1. Since probe predicates are only
useful if they reference the first column in the table, per
"orderUsefulPredicates(...)" of PredicateList.java:
else if (pred.isInListProbePredicate()
&& (indexPosition > 0))
{
/* If the predicate is an IN-list probe predicate
* then we only consider it to be useful if the
* referenced column is the *first* one in the
* index (i.e. if (indexPosition == 0)). Otherwise
* the predicate would be treated as a qualifier
* for store, which could lead to incorrect
* results.
*/
the probe predicate is not useful. That in turn means that when it comes time
to generate the IN list operator, we'll "revert" back to the original
InListOperatorNode--i.e. we will generate the InListOperatorNode *instead of*
generating the probe predicate. This is found in the generateExpression()
method of BinaryOperatorNode:
if (ilon != null)
{
ilon.generateExpression(acb, mb);
return;
}
But there's a problem here: as mentioned above, ilon (the InListOperatorNode)
still has a left operand that points to a column from the *subquery*. Since we
flattened the subquery out, that left operand is no longer valid--and that
ultimately causes an execution time NPE because we try to apply the IN list
restriction to a column from a subquery that does not exist.
I tried a one-line fix to this code that seems to have resolved the issue:
if (ilon != null)
{
ilon.setLeftOperand(this.leftOperand); // Added this line
ilon.generateExpression(acb, mb);
return;
}
(with appropriate code comments, of course).
This has the effect of making sure that when we "revert" back to the original
InListOperatorNode generation, we'll still generate the correct
leftOperand--i.e. the left operand as it exists in the "probe predicate" upon
completion of optimization.
I'm attaching this small fix as d3253_v1.patch. I have yet to run the
regression tests (they are running now), but I thought I'd post my findings for
early revi
[jira] Updated: (DERBY-3242) ij doesn't understand bracketed comments
[ https://issues.apache.org/jira/browse/DERBY-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3242: -- Attachment: Derby-3241-v2.txt Thanks Knut for spending the time to review my previous patch proposal. I have prepared a new patch proposal (Derby-3241-v2.txt) that incorporates your suggestions. In particular: Scripts ending with bracketed comments are correctly handled. I cleaned up the indentation to be in the style of the surrounding code. Added the missing constants and removed the unnecessary state flags. Ran derbyAll and suites.All and saw no errors I could attribute to this patch. > ij doesn't understand bracketed comments > > > Key: DERBY-3242 > URL: https://issues.apache.org/jira/browse/DERBY-3242 > Project: Derby > Issue Type: Bug > Components: SQL, Tools >Affects Versions: 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: James F. Adams > Attachments: comment.sql, comment2.sql, Derby-3241-v2.txt, > Derby-3242.txt > > > When I execute this sql script in ij > -- > create table t (x int); > /* > insert into t values 1, 2, 3; > insert into t values 4, 5, 6; > */ > -- > the first INSERT statement in the comment is correctly ignored, but the > second one is executed. So after running the script, table T contains these > rows: > ij> select * from t; > X > --- > 4 > 5 > 6 > 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: thanks to Kathey for cat-herding 10.3.2
Rick Hillegas <[EMAIL PROTECTED]> writes: > Hi Kathey, > > Thanks for all the hard work getting 10.3.2 out the door! +1 !! Dag
[jira] Updated: (DERBY-3260) NullPointerException caused by race condition in GenericActivationHolder
[ https://issues.apache.org/jira/browse/DERBY-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Yokota updated DERBY-3260: - Attachment: GenericActivationHolder.java.diff > NullPointerException caused by race condition in GenericActivationHolder > > > Key: DERBY-3260 > URL: https://issues.apache.org/jira/browse/DERBY-3260 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, > 10.2.2.0, 10.3.1.4 >Reporter: Robert Yokota >Priority: Blocker > Attachments: GenericActivationHolder.java.diff > > > I have a stress test using Derby 10.3.1.4 which is executing the same > PreparedStatement using multiple threads concurrently and I consistently get > the following NPE after several hours of running: > 2007-12-07 00:48:10.914 GMT Thread[pool-5-thread-25,5,main] (XID = 1219661), > (SESSIONID = 377), (DATABASE = /usr/ironhide/var/db/opera/derby), (DRDAID = > null), Failed Statement is: select rdbmsvaria0_.GUID_AND_INDEX as GUID1_3_0_, > rdbmsvaria0_.VALUE2 as VALUE2_3_0_, rdbmsvaria0_.HOLDER_GUID as HOLDER3_3_0_, > rdbmsvaria0_.VALUE_TYPE as VALUE4_3_0_, rdbmsvaria0_.VALUE_GUID as > VALUE5_3_0_, rdbmsvaria0_.DELETED as DELETED3_0_ from VARIABLE rdbmsvaria0_ > where rdbmsvaria0_.GUID_AND_INDEX=? with 1 parameters begin parameter #1: > 9C202AB9E8356288A9320C9C383A4D2F-11 :end parameter > java.lang.NullPointerException > at > org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:271) > at > org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:368) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1203) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:275) > at > org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186) > at org.hibernate.loader.Loader.getResultSet(Loader.java:1787) > at org.hibernate.loader.Loader.doQuery(Loader.java:674) > at > org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) > at org.hibernate.loader.Loader.loadEntity(Loader.java:1860) > at > org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48) > at > org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42) > at > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3044) > at > org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:395) > at > org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375) > at > org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139) > at > org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:179) > at > org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878) > at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815) > at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808) > at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301) > at $Proxy41.get(Unknown Source) > at > com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getRdbmsVariable(RdbmsContextHolder.java:108) > at > com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getVariable(RdbmsContextHolder.java:94) > at com.approuter.maestro.vm.Frame.getParameter(Frame.java:218) > at com.approuter.maestro.vm.Task.getParameter(Task.java:1267) > at > com.approuter.maestro.vm.CallContextImpl.setOutputParameter(CallContextImpl.java:195) > at > com.approuter.maestro.vm.CallContextImpl.getOutputParameterWriter(CallContextImpl.java:264) > at > com.approuter.maestro.sdk.mpi.DynamicExecutableActivity$3$1.getWriter(DynamicExecutableActivity.java:249) > at > com.approuter.module.xml.XmlSerializeTextActivity$XmlSerializeTextActivityInstance.serialize(XmlSerializeTextActivity.java:43) > at sun.reflect.GeneratedMethodAccessor161.invoke(Unknown
[jira] Commented: (DERBY-3260) NullPointerException caused by race condition in GenericActivationHolder
[ https://issues.apache.org/jira/browse/DERBY-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551630 ] Robert Yokota commented on DERBY-3260: -- I've attached a patch file. I'm not working on this any longer -- I've suggested the fix (just two lines) and my company has successfully run hundreds of tests with it. I would suggest someone else verify my analysis of the race condition and then commit the change. > NullPointerException caused by race condition in GenericActivationHolder > > > Key: DERBY-3260 > URL: https://issues.apache.org/jira/browse/DERBY-3260 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, > 10.2.2.0, 10.3.1.4 >Reporter: Robert Yokota >Priority: Blocker > Attachments: GenericActivationHolder.java.diff > > > I have a stress test using Derby 10.3.1.4 which is executing the same > PreparedStatement using multiple threads concurrently and I consistently get > the following NPE after several hours of running: > 2007-12-07 00:48:10.914 GMT Thread[pool-5-thread-25,5,main] (XID = 1219661), > (SESSIONID = 377), (DATABASE = /usr/ironhide/var/db/opera/derby), (DRDAID = > null), Failed Statement is: select rdbmsvaria0_.GUID_AND_INDEX as GUID1_3_0_, > rdbmsvaria0_.VALUE2 as VALUE2_3_0_, rdbmsvaria0_.HOLDER_GUID as HOLDER3_3_0_, > rdbmsvaria0_.VALUE_TYPE as VALUE4_3_0_, rdbmsvaria0_.VALUE_GUID as > VALUE5_3_0_, rdbmsvaria0_.DELETED as DELETED3_0_ from VARIABLE rdbmsvaria0_ > where rdbmsvaria0_.GUID_AND_INDEX=? with 1 parameters begin parameter #1: > 9C202AB9E8356288A9320C9C383A4D2F-11 :end parameter > java.lang.NullPointerException > at > org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:271) > at > org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:368) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1203) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:275) > at > org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186) > at org.hibernate.loader.Loader.getResultSet(Loader.java:1787) > at org.hibernate.loader.Loader.doQuery(Loader.java:674) > at > org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) > at org.hibernate.loader.Loader.loadEntity(Loader.java:1860) > at > org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48) > at > org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42) > at > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3044) > at > org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:395) > at > org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375) > at > org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139) > at > org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:179) > at > org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878) > at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815) > at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808) > at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301) > at $Proxy41.get(Unknown Source) > at > com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getRdbmsVariable(RdbmsContextHolder.java:108) > at > com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getVariable(RdbmsContextHolder.java:94) > at com.approuter.maestro.vm.Frame.getParameter(Frame.java:218) > at com.approuter.maestro.vm.Task.getParameter(Task.java:1267) > at > com.approuter.maestro.vm.CallContextImpl.setOutputParameter(CallContextImpl.java:195) > at > com.approuter.maestro.vm.CallContextImpl.getOutputParameterWriter(CallContextImpl.java:264) > at > com.approuter.maestro.sdk.mpi.DynamicExecutableActivity$3$1.get
[jira] Commented: (DERBY-3273) convert derbynet/testconnection.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551626 ] Kathey Marsden commented on DERBY-3273: --- of course you are right, the two commands end up testing the same thing. I will remove the second. > convert derbynet/testconnection.java to junit > - > > Key: DERBY-3273 > URL: https://issues.apache.org/jira/browse/DERBY-3273 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3273_diff.txt, derby-3273_diff2.txt > > > convert derbynet/testconnection.java to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3273) convert derbynet/testconnection.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551622 ] Daniel John Debrunner commented on DERBY-3273: -- Can you comment what's going on here? +String currentHost = TestConfiguration.getCurrent().getHostName(); +int currentPort = TestConfiguration.getCurrent().getPort(); +NetworkServerControl nsctrl = NetworkServerTestSetup.getNetworkServerControl(); +nsctrl.ping(); +nsctrl = new NetworkServerControl(privInetAddressGetByName(currentHost), +currentPort); +nsctrl.ping(); What's different about the second ping that requires additional testing? Seems to me that if SSL is not enabled then the two pings are testing the same logic, if SSL is enabled then won't the second ping fail? > convert derbynet/testconnection.java to junit > - > > Key: DERBY-3273 > URL: https://issues.apache.org/jira/browse/DERBY-3273 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3273_diff.txt, derby-3273_diff2.txt > > > convert derbynet/testconnection.java to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3273) convert derbynet/testconnection.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3273: -- Derby Info: [Patch Available] > convert derbynet/testconnection.java to junit > - > > Key: DERBY-3273 > URL: https://issues.apache.org/jira/browse/DERBY-3273 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3273_diff.txt, derby-3273_diff2.txt > > > convert derbynet/testconnection.java to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3273) convert derbynet/testconnection.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3273: -- Attachment: derby-3273_diff2.txt A new patch addressing Myrna's and Dan's comments. > convert derbynet/testconnection.java to junit > - > > Key: DERBY-3273 > URL: https://issues.apache.org/jira/browse/DERBY-3273 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3273_diff.txt, derby-3273_diff2.txt > > > convert derbynet/testconnection.java to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3244) NullPointerException in ....B2IRowLocking3.searchLeftAndLockPreviousKey
[ https://issues.apache.org/jira/browse/DERBY-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali resolved DERBY-3244. --- Resolution: Fixed Fix Version/s: 10.0.2.0 10.3.2.1 10.4.0.0 > NullPointerException in B2IRowLocking3.searchLeftAndLockPreviousKey > --- > > Key: DERBY-3244 > URL: https://issues.apache.org/jira/browse/DERBY-3244 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Store >Affects Versions: 10.3.2.1, 10.4.0.0 > Environment: All ? >Reporter: Ole Solberg >Assignee: Mike Matrigali > Fix For: 10.4.0.0, 10.3.2.1, 10.0.2.0 > > > The last week(48) we have seen a large number of this failure. > It was categorized as DERBY-2589 but these instances all have the NPE. > Exception while trying to insert row number: 52 > ERROR XJ001: Java exception: ': java.lang.NullPointerException'. > java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.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.executeStatement(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown > Source) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.createAndLoadTable(OnlineCompressTest.java:140) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.deleteAllRows(OnlineCompressTest.java:494) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.test1(OnlineCompressTest.java:913) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.testList(OnlineCompressTest.java:1500) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.main(OnlineCompressTest.java:1520) > Caused by: java.lang.NullPointerException > at > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.searchLeftAndLockPreviousKey(Unknown > Source) > at > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockNonScanPreviousRow(Unknown > Source) > at > org.apache.derby.impl.store.access.btree.BTreeController.doIns(Unknown Source) > at > org.apache.derby.impl.store.access.btree.BTreeController.insert(Unknown > Source) > at > org.apache.derby.impl.store.access.btree.index.B2IController.insert(Unknown > Source) > at > org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown > Source) > at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown > Source) > at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown Source) > at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown > Source) > at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown > Source) > at > org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown > Source) > at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown > Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > ... 8 more > The error statistics shows the occurrences: > (http://dbtg.thresher.com/derby/test/stats_today.html / > http://dbtg.thresher.com/derby/test/stats_newest.html ) > http://dbtg.thresher.com/derby/test/statistics/2589_48.html : > JIRA: 2589, Week: 48 600335-598009 > 598009 Daily jvm1.4 vista > 598009 Daily jvm1.6 lin > 598341 Daily jvm1.6 solN+1 > 598341 Daily jvm1.6 sparc > 598354 10.3Branch jvm1.5 lin > 598376 trunk16 jvmAll JDK16Jvm1.5SunOS-5.10_i86pc-i386 > 598692 Daily jvm1.6 sol > 598729 trunk16 jvmAll JDK16Jvm1.6SunOS-5.10_i86pc-i386 > 599062 Daily jvm1.5 lin > 599088 trunk15 jvm1.5 SunOS-5.10_i86pc-i386 > 599088 trunk15 jvm1.5 SunOS-5.10_sun4u-sparc > 599088 trunk16 jvmAll JDK16Jvm1.5SunOS-5.10_i86pc-i386 > 600335 Daily jvm1.4 lin > Mon Dec 3 09:36:11 CET 2007 > http://dbtg.thresher.com/derby/test/statistics/2589_47.html seems to be the > first occurence: > JIRA: 2589, Week: 47 597885-597885 > 597885 Daily jvm1.6 lin > Mon Dec 3 09:36:13
[jira] Updated: (DERBY-3274) Developer's Guide has duplicate information on database connections
[
https://issues.apache.org/jira/browse/DERBY-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim Haase updated DERBY-3274:
-
Attachment: DERBY-3274.stat
DERBY-3274.zip
DERBY-3274.diff
Attaching DERBY-3274.diff, DERBY-3274.zip, and DERBY-3274.stat, containing
modifications and deletions of the following files:
M src/devguide/cdevdvlp91854.dita
D src/devguide/cdevdvlp40170.dita
D src/devguide/tdevdvlp38381.dita
M src/devguide/derbydev.ditamap
D src/devguide/rdevdvlp38881.dita
M src/devguide/cdevdvlp17453.dita
M src/devguide/cdevdvlp40653.dita
M src/devguide/cdevspecial29620.dita
M src/devguide/cdevdvlp39409.dita
D src/devguide/cdevdvlp10252.dita
D src/devguide/cdevdvlp25174.dita
> Developer's Guide has duplicate information on database connections
> ---
>
> Key: DERBY-3274
> URL: https://issues.apache.org/jira/browse/DERBY-3274
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.3.1.4
>Reporter: Kim Haase
>Assignee: Kim Haase
> Attachments: DERBY-3274.diff, DERBY-3274.stat, DERBY-3274.zip
>
>
> The Developer's Guide contains some duplicated information about database
> connections and related topics. One glaring example is the short top-level
> section "Embedded Derby basics", which comes after a longer section of the
> same title under "JDBC applications and Derby basics". The information in the
> short section that doesn't duplicate information elsewhere needs to be
> included in appropriate places in the long section (and elsewhere as
> appropriate). The topics for the short section should then be removed.
> Specifically:
> For the two introductory topics, the two sentences from
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
> embedded basics") should replace the sentence in
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp39409.html (same title),
> since they offer more substance.
> The first sentence of
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
> Derby JDBC driver"), "The Derby driver class name for the embedded
> environment is org.apache.derby.jdbc.EmbeddedDriver.", should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
> driver".
> Most of http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html
> ("Embedded Derby JDBC database connection URL") should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html, "Derby JDBC
> database connection URL". Also, this text should cross-reference the sections
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp91854.html ("Accessing
> databases from the classpath") and
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp24155.html ("Accessing
> databases from a jar or zip file"). In
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html itself, the
> sentence "For more information about what you can specify with the Derby
> connection URL, see "Examples"." is incorrect. I believe this should be a
> cross-reference to the section
> http://db.apache.org/derby/docs/dev/devguide/rdevdvlp22102.html ("Database
> connection examples"). Also, the sentence "For detailed reference about
> attributes and values, as well as syntax of the database connection URL, see
> the "Derby Database Connection URL Syntax" in the Derby Reference Manual."
> refers, I believe, to the wrong section. That particular topic contains only
> a couple of sentences and refers back to the Developer's Guide. I think the
> sentence should say instead, "For detailed reference about attributes and
> values, see "Setting attributes for the database connection URL" in the Derby
> Reference Manual." (The syntax is actually covered more fully in the
> Developer's Guide than in the Reference Manual.)
> The last paragraph of
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
> nested connection") should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevspecial29620.html,
> "Database-side JDBC procedures and nested connections". (This topic also has
> a couple of minor typographical issues that can be fixed at the same time.)
> The example of the use of the jdbc.drivers system property should be moved
> from http://db.apache.org/derby/docs/dev/devguide/tdevdvlp38381.html
> ("Starting Derby as an embedded database") to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
> driver".
> The following sections can then be removed:
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
> embedded basics")
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
> Derby JDBC driver")
> http://db.apa
[jira] Updated: (DERBY-3274) Developer's Guide has duplicate information on database connections
[
https://issues.apache.org/jira/browse/DERBY-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim Haase updated DERBY-3274:
-
Derby Info: [Patch Available]
> Developer's Guide has duplicate information on database connections
> ---
>
> Key: DERBY-3274
> URL: https://issues.apache.org/jira/browse/DERBY-3274
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.3.1.4
>Reporter: Kim Haase
>Assignee: Kim Haase
> Attachments: DERBY-3274.diff, DERBY-3274.stat, DERBY-3274.zip
>
>
> The Developer's Guide contains some duplicated information about database
> connections and related topics. One glaring example is the short top-level
> section "Embedded Derby basics", which comes after a longer section of the
> same title under "JDBC applications and Derby basics". The information in the
> short section that doesn't duplicate information elsewhere needs to be
> included in appropriate places in the long section (and elsewhere as
> appropriate). The topics for the short section should then be removed.
> Specifically:
> For the two introductory topics, the two sentences from
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
> embedded basics") should replace the sentence in
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp39409.html (same title),
> since they offer more substance.
> The first sentence of
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
> Derby JDBC driver"), "The Derby driver class name for the embedded
> environment is org.apache.derby.jdbc.EmbeddedDriver.", should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
> driver".
> Most of http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html
> ("Embedded Derby JDBC database connection URL") should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html, "Derby JDBC
> database connection URL". Also, this text should cross-reference the sections
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp91854.html ("Accessing
> databases from the classpath") and
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp24155.html ("Accessing
> databases from a jar or zip file"). In
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html itself, the
> sentence "For more information about what you can specify with the Derby
> connection URL, see "Examples"." is incorrect. I believe this should be a
> cross-reference to the section
> http://db.apache.org/derby/docs/dev/devguide/rdevdvlp22102.html ("Database
> connection examples"). Also, the sentence "For detailed reference about
> attributes and values, as well as syntax of the database connection URL, see
> the "Derby Database Connection URL Syntax" in the Derby Reference Manual."
> refers, I believe, to the wrong section. That particular topic contains only
> a couple of sentences and refers back to the Developer's Guide. I think the
> sentence should say instead, "For detailed reference about attributes and
> values, see "Setting attributes for the database connection URL" in the Derby
> Reference Manual." (The syntax is actually covered more fully in the
> Developer's Guide than in the Reference Manual.)
> The last paragraph of
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
> nested connection") should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevspecial29620.html,
> "Database-side JDBC procedures and nested connections". (This topic also has
> a couple of minor typographical issues that can be fixed at the same time.)
> The example of the use of the jdbc.drivers system property should be moved
> from http://db.apache.org/derby/docs/dev/devguide/tdevdvlp38381.html
> ("Starting Derby as an embedded database") to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
> driver".
> The following sections can then be removed:
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
> embedded basics")
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
> Derby JDBC driver")
> http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html ("Embedded
> Derby JDBC database connection URL")
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
> nested connection")
> http://db.apache.org/derby/docs/dev/devguide/tdevdvlp38381.html ("Starting
> Derby as an embedded database")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3261) 'Empty right rows returned = 0' expected '... = 1' in lang/outerjoin.sql
[ https://issues.apache.org/jira/browse/DERBY-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-3261. Resolution: Fixed Fix Version/s: 10.4.0.0 10.3.2.2 Merged changes from trunk(603823) into 10.3 codeline(r603980). All the tests ran fine. > 'Empty right rows returned = 0' expected '... = 1' in lang/outerjoin.sql > > > Key: DERBY-3261 > URL: https://issues.apache.org/jira/browse/DERBY-3261 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: OS: Solaris 10 6/06 s10x_u2wos_09a X86 64bits - SunOS > 5.10 Generic_118855-14 > JVM: Sun Microsystems Inc. 1.6.0_02-b05 >Reporter: Ole Solberg >Assignee: Mamta A. Satoor >Priority: Minor > Fix For: 10.3.2.2, 10.4.0.0 > > > See > http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/601833-derbyall_diff.txt > Failure Details: > * Diff file derbyall/derbylang/outerjoin.diff > *** Start: outerjoin jdk1.6.0_02 derbyall:derbylang 2007-12-06 22:22:35 *** > 1737 del > < Empty right rows returned = 1 > 1737a1737 > > Empty right rows returned = 0 > Test Failed. > *** End: outerjoin jdk1.6.0_02 derbyall:derbylang 2007-12-06 22:22:43 *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.
[ https://issues.apache.org/jira/browse/DERBY-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3231: -- manish have you had a chance to look at DERBY-3257, it is another query which army tested before DERBY-691 and stopped after DERBY-691. Looks like mamta checked it against this fix and still broken. Any insight whether the issue might be similar to what you addressed in this issue? > Sorting on COUNT with OR and GROUP BY delivers wrong results. > - > > Key: DERBY-3231 > URL: https://issues.apache.org/jira/browse/DERBY-3231 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.1.4 > Environment: Eclipse 3.2.2; java 1.5.0_11; >Reporter: Peter Balon >Assignee: Manish Khettry >Priority: Critical > Attachments: d3231_v2.patch, order_by_bug.diff.txt > > > The result of the select is not sorted in "order by COUNT(*) DESC" or "order > by COUNT(*) ASC" > create table yy (a double, b double); > insert into yy values (2, 4); > insert into yy values (5, 7); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (9, 7); > select b, COUNT(*) AS "COUNT_OF", SUM(b) AS "sum b" > from yy > where a = 5 or a = 2 > group by b > order by COUNT(*) asc > -- same result as: > select b, COUNT(*) AS "COUNT_OF", SUM(b) AS "sum b" > from yy > where a = 5 or a = 2 > group by b > order by COUNT(*) desc -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3274) Developer's Guide has duplicate information on database connections
[
https://issues.apache.org/jira/browse/DERBY-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551570
]
Kim Haase commented on DERBY-3274:
--
One more change needs to be made:
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp91854.html ("Accessing
databases from the classpath") has a crossreference to
http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html ("Embedded
Derby JDBC database connection URL") for "more information". In fact it is
cdevdvlp91854.html itself that has most of this information -- not
rdevdvlp38881.html or the file to which its information was moved. So the
cross-reference should be cut.
> Developer's Guide has duplicate information on database connections
> ---
>
> Key: DERBY-3274
> URL: https://issues.apache.org/jira/browse/DERBY-3274
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.3.1.4
>Reporter: Kim Haase
>Assignee: Kim Haase
>
> The Developer's Guide contains some duplicated information about database
> connections and related topics. One glaring example is the short top-level
> section "Embedded Derby basics", which comes after a longer section of the
> same title under "JDBC applications and Derby basics". The information in the
> short section that doesn't duplicate information elsewhere needs to be
> included in appropriate places in the long section (and elsewhere as
> appropriate). The topics for the short section should then be removed.
> Specifically:
> For the two introductory topics, the two sentences from
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
> embedded basics") should replace the sentence in
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp39409.html (same title),
> since they offer more substance.
> The first sentence of
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
> Derby JDBC driver"), "The Derby driver class name for the embedded
> environment is org.apache.derby.jdbc.EmbeddedDriver.", should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
> driver".
> Most of http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html
> ("Embedded Derby JDBC database connection URL") should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html, "Derby JDBC
> database connection URL". Also, this text should cross-reference the sections
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp91854.html ("Accessing
> databases from the classpath") and
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp24155.html ("Accessing
> databases from a jar or zip file"). In
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html itself, the
> sentence "For more information about what you can specify with the Derby
> connection URL, see "Examples"." is incorrect. I believe this should be a
> cross-reference to the section
> http://db.apache.org/derby/docs/dev/devguide/rdevdvlp22102.html ("Database
> connection examples"). Also, the sentence "For detailed reference about
> attributes and values, as well as syntax of the database connection URL, see
> the "Derby Database Connection URL Syntax" in the Derby Reference Manual."
> refers, I believe, to the wrong section. That particular topic contains only
> a couple of sentences and refers back to the Developer's Guide. I think the
> sentence should say instead, "For detailed reference about attributes and
> values, see "Setting attributes for the database connection URL" in the Derby
> Reference Manual." (The syntax is actually covered more fully in the
> Developer's Guide than in the Reference Manual.)
> The last paragraph of
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
> nested connection") should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevspecial29620.html,
> "Database-side JDBC procedures and nested connections". (This topic also has
> a couple of minor typographical issues that can be fixed at the same time.)
> The example of the use of the jdbc.drivers system property should be moved
> from http://db.apache.org/derby/docs/dev/devguide/tdevdvlp38381.html
> ("Starting Derby as an embedded database") to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
> driver".
> The following sections can then be removed:
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
> embedded basics")
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
> Derby JDBC driver")
> http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html ("Embedded
> Derby JDBC database connection URL")
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
> nested connection")
>
[jira] Updated: (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:all-tabpanel ] Daniel John Debrunner updated DERBY-3221: - Affects Version/s: 10.3.2.1 > "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 > > 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-3257) SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB
[ https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551569 ] Mamta A. Satoor commented on DERBY-3257: My trunk client is at revision 603368 $ svn info Path: . URL: https://svn.apache.org/repos/asf/db/derby/code/trunk Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 603368 Node Kind: directory Schedule: normal Last Changed Author: kmarsden Last Changed Rev: 603301 Last Changed Date: 2007-12-11 09:03:01 -0800 (Tue, 11 Dec 2007) Properties Last Updated: 2007-11-26 09:22:05 -0800 (Mon, 26 Nov 2007) When I run the attached test case with revision 603368, I get incorrect results, ie only one count is returned back. $ java org.apache.derbyTesting.functionTests.tests.lang.DERBY_3257_Repro Database product: Apache Derby Database version: 10.4.0.0 alpha - (1) Driver name: Apache Derby Embedded JDBC Driver Driver version: 10.4.0.0 alpha - (1) result: 2 > SELECT with HAVING clause containing OR conditional incorrectly return 1 row > - should return 2 rows - works correctly with 10.2 DB > -- > > Key: DERBY-3257 > URL: https://issues.apache.org/jira/browse/DERBY-3257 > Project: Derby > Issue Type: Bug >Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 >Reporter: Stan Bradbury > Attachments: TestHaving.java > > > Attached program demonstrates the problem. Only one count is returned > (matching CODE= GBR) - the count of CODE=CHA is not returned. Works fine > with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 > database (soft upgrade). > Query: > SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 > GROUP BY t0.CODE > HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL > Incorrect results (see last line): > Database product: Apache Derby > Database version: 10.3.1.5 - (579866) > Driver name: Apache Derby Embedded JDBC Driver > Driver version: 10.3.1.5 - (579866) > result: 2 > Correct results: > Database product: Apache Derby > Database version: 10.2.2.0 - (485682) > Driver name: Apache Derby Embedded JDBC Driver > Driver version: 10.2.2.0 - (485682) > result: 4 > result: 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551568 ] Daniel John Debrunner commented on DERBY-2998: -- > do you believe that ROW_NUMBER OVER () is a non-standard use of ROW_NUMBER? No idea, Mamta points out that the syntax grammar allows it. I haven't gone through all the syntax and general rules in 6.10 & 7.11 to see if there are additional conditions that would lead an empty window specification to be invalid. (e.g. the syntax grammar for routine creation allows multiple LANGUAGE clauses, but the rules specify "at most one" language clause, so the syntax grammar is not the final say on if a statement is valid or not) > Add support for ROW_NUMBER() window function > > > Key: DERBY-2998 > URL: https://issues.apache.org/jira/browse/DERBY-2998 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Thomas Nielsen >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d2998-4.diff, d2998-4.stat, d2998-5.diff, d2998-5.stat, > d2998-6.diff, d2998-6.stat, d2998-test.diff, d2998-test.stat, > d2998-test2.diff, d2998-test2.stat > > > As part of implementing the overall OLAP Operations features of SQL > (DERBY-581), implement the ROW_NUMBER() window function. > More information about this feature is available at > http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3273) convert derbynet/testconnection.java to junit
[
https://issues.apache.org/jira/browse/DERBY-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551567
]
Kathey Marsden commented on DERBY-3273:
---
Dan said...
>+ try {
>+ nsctrl = new >NetworkServerControl(InetAddress.getByName("notthere"), 1527);
>+ nsctrl.ping();
>+ fail("Should not have been able to ping host >\"notthere\"");
>I think this is a dangerous coding style for tests, which >method call are you
>expecting to fail? Only the method >expected to fail should be in the try
>catch block
In fact the failure was happening in the InetAddress.getByName("notthere"),
call, so we never got to the ping. It was a security exception, but when I
added the permissions and privilege block, it failed with an UnknownHost
exception, so the test itself does not make much sense for ping with the API.
I'll take the unknown host test out of testPing.
> convert derbynet/testconnection.java to junit
> -
>
> Key: DERBY-3273
> URL: https://issues.apache.org/jira/browse/DERBY-3273
> Project: Derby
> Issue Type: Test
> Components: Test
>Affects Versions: 10.4.0.0
>Reporter: Kathey Marsden
>Assignee: Kathey Marsden
>Priority: Minor
> Attachments: derby-3273_diff.txt
>
>
> convert derbynet/testconnection.java to junit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3273) convert derbynet/testconnection.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3273: -- Derby Info: (was: [Patch Available]) > convert derbynet/testconnection.java to junit > - > > Key: DERBY-3273 > URL: https://issues.apache.org/jira/browse/DERBY-3273 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3273_diff.txt > > > convert derbynet/testconnection.java to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.
[ https://issues.apache.org/jira/browse/DERBY-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A B updated DERBY-3231: --- Derby Info: [Regression] (was: [Regression, Existing Application Impact, Patch Available]) > Sorting on COUNT with OR and GROUP BY delivers wrong results. > - > > Key: DERBY-3231 > URL: https://issues.apache.org/jira/browse/DERBY-3231 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.1.4 > Environment: Eclipse 3.2.2; java 1.5.0_11; >Reporter: Peter Balon >Assignee: Manish Khettry >Priority: Critical > Attachments: d3231_v2.patch, order_by_bug.diff.txt > > > The result of the select is not sorted in "order by COUNT(*) DESC" or "order > by COUNT(*) ASC" > create table yy (a double, b double); > insert into yy values (2, 4); > insert into yy values (5, 7); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (9, 7); > select b, COUNT(*) AS "COUNT_OF", SUM(b) AS "sum b" > from yy > where a = 5 or a = 2 > group by b > order by COUNT(*) asc > -- same result as: > select b, COUNT(*) AS "COUNT_OF", SUM(b) AS "sum b" > from yy > where a = 5 or a = 2 > group by b > order by COUNT(*) desc -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.
[ https://issues.apache.org/jira/browse/DERBY-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A B updated DERBY-3231: --- Attachment: d3231_v2.patch I added a single test case to the original patch to also check that a sort in ascending order works (the original patch only checked desc), so I'm attaching the patch with that change as d3231_v2.patch. Committed with svn # 603954: http://svn.apache.org/viewvc?rev=603954&view=rev Thanks again to Manish for picking this one up and offering a solution in such quick time. > Sorting on COUNT with OR and GROUP BY delivers wrong results. > - > > Key: DERBY-3231 > URL: https://issues.apache.org/jira/browse/DERBY-3231 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.1.4 > Environment: Eclipse 3.2.2; java 1.5.0_11; >Reporter: Peter Balon >Assignee: Manish Khettry >Priority: Critical > Attachments: d3231_v2.patch, order_by_bug.diff.txt > > > The result of the select is not sorted in "order by COUNT(*) DESC" or "order > by COUNT(*) ASC" > create table yy (a double, b double); > insert into yy values (2, 4); > insert into yy values (5, 7); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (9, 7); > select b, COUNT(*) AS "COUNT_OF", SUM(b) AS "sum b" > from yy > where a = 5 or a = 2 > group by b > order by COUNT(*) asc > -- same result as: > select b, COUNT(*) AS "COUNT_OF", SUM(b) AS "sum b" > from yy > where a = 5 or a = 2 > group by b > order by COUNT(*) desc -- 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 603671 - Sun DBTG
[Auto-generated mail] *Daily* 603671/2007-12-12 18:00:13 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 1274273 071.70% derbyall 01013110131 0 1265.85% suitesAll linN+1 1274273 0 .% derbyall 01013110131 0 .% suitesAll sles 1274273 071.31% derbyall 01013110131 0 856.97% suitesAll sol 1274273 075.68% derbyall 01013110131 0 1422.25% suitesAll solN+1 1274273 084.18% derbyall 01013110131 0 1322.68% suitesAll sparc 1274273 065.64% derbyall 01013110131 0 347.54% suitesAll vista 1274273 0 .% derbyall 091109110 0 429.51% suitesAll w2003 1274273 0 .% derbyall 091109110 0 234.44% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-603671.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/603671_bySig.html *Jvm: 1.5* lin 1275274 071.67% derbyall 084158415 0 864.06% suitesAll linN+1 2275273 0 .% derbyall 084158415 0 .% suitesAll sles 1275274 070.73% derbyall 084158415 0 557.71% suitesAll sol 1275274 079.79% derbyall 084158415 0 829.71% suitesAll solN+1 1275274 087.97% derbyall 084158415 0 771.26% suitesAll sparc 1275274 066.62% derbyall 084158415 0 669.65% suitesAll vista 1275274 072.07% derbyall 073947394 0 396.98% suitesAll w2003 1275274 073.83% derbyall 073947394 0 251.49% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-603671.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/603671_bySig.html *Jvm: 1.4* lin 1272271 273.09% derbyall 083638363 0 782.62% suitesAll linN+1 1272271 2 .% derbyall F:0,E:183638362 0 .% suitesAll sles 1272271 270.59% derbyall 083638363 0 511.12% suitesAll sol 1272271 277.62% derbyall 083638363 0 668.73% suitesAll solN+1 1272271 289.44% derbyall 083638363 0 726.80% suitesAll sparc 1272271 266.94% derbyall 083638363 0 685.51% suitesAll vista 1272271 2 .% derbyall 073427342 0 386.20% suitesAll w2003 1272271 2 .% derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-603671.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/603671_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/603671.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551555 ] Mamta A. Satoor commented on DERBY-2998: I thought I would chime in here and say that ROW_NUMBER OVER () is SQL standards compliant. SQL spec has following (Section 7.11 ) ::= ::= [ ] [ ] [ ] [ ] This indicates that window specificatoin details are optional. > Add support for ROW_NUMBER() window function > > > Key: DERBY-2998 > URL: https://issues.apache.org/jira/browse/DERBY-2998 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Thomas Nielsen >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d2998-4.diff, d2998-4.stat, d2998-5.diff, d2998-5.stat, > d2998-6.diff, d2998-6.stat, d2998-test.diff, d2998-test.stat, > d2998-test2.diff, d2998-test2.stat > > > As part of implementing the overall OLAP Operations features of SQL > (DERBY-581), implement the ROW_NUMBER() window function. > More information about this feature is available at > http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.
[ https://issues.apache.org/jira/browse/DERBY-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551551 ] A B commented on DERBY-3231: manish> I thought it was better to fix the wrong results and look at optimizations later on as a separate bug. bryanp> I agree with your assessment that the highest priority is for the query to bryanp> return the right results. Okay, so it looks like there is agreement here :) I just wanted to bring up the fact that, in getting one query to return correct results, we're effectively *disabling* an *existing* optimization for another query that currently works correctly. To say "get it working, then improve it" is perfectly okay; to say "get it working but regress other optimizations, then fix those other optimizations later" is also probably okay, but perhaps slightly more risky as a general principle. In any event, I'm +1 to Bryan's proposal given the apparent unlikelihood of the to-be-disabled optimization (ex. for MAX()) showing up in a user's environment. manish> +1 on your proposal. Manish, are you volunteering to implement the proposal, i.e. to 1) add more test cases to the regression suite, and 2) file another Jira? My derbyall and suites.All with the patch ran cleanly (only failure was the known failure of outerjoin.sql, which is unrelated and has since been fixed). So I can commit order_by_bug.diff now and the additional test cases can perhaps be added as a separate patch/commit. Does that sound okay? > Sorting on COUNT with OR and GROUP BY delivers wrong results. > - > > Key: DERBY-3231 > URL: https://issues.apache.org/jira/browse/DERBY-3231 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.1.4 > Environment: Eclipse 3.2.2; java 1.5.0_11; >Reporter: Peter Balon >Assignee: Manish Khettry >Priority: Critical > Attachments: order_by_bug.diff.txt > > > The result of the select is not sorted in "order by COUNT(*) DESC" or "order > by COUNT(*) ASC" > create table yy (a double, b double); > insert into yy values (2, 4); > insert into yy values (5, 7); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (2, 3); > insert into yy values (9, 7); > select b, COUNT(*) AS "COUNT_OF", SUM(b) AS "sum b" > from yy > where a = 5 or a = 2 > group by b > order by COUNT(*) asc > -- same result as: > select b, COUNT(*) AS "COUNT_OF", SUM(b) AS "sum b" > from yy > where a = 5 or a = 2 > group by b > order by COUNT(*) desc -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3261) 'Empty right rows returned = 0' expected '... = 1' in lang/outerjoin.sql
[ https://issues.apache.org/jira/browse/DERBY-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551549 ] Mamta A. Satoor commented on DERBY-3261: Thanks Ole for checking that the fix actually worked with the tinerbox runs. I am running derbyall right now on 10.3 codeline and then will merge the fix there too. Junit tests ran fine on 10.3 on the merged codeline. > 'Empty right rows returned = 0' expected '... = 1' in lang/outerjoin.sql > > > Key: DERBY-3261 > URL: https://issues.apache.org/jira/browse/DERBY-3261 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: OS: Solaris 10 6/06 s10x_u2wos_09a X86 64bits - SunOS > 5.10 Generic_118855-14 > JVM: Sun Microsystems Inc. 1.6.0_02-b05 >Reporter: Ole Solberg >Assignee: Mamta A. Satoor >Priority: Minor > > See > http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/601833-derbyall_diff.txt > Failure Details: > * Diff file derbyall/derbylang/outerjoin.diff > *** Start: outerjoin jdk1.6.0_02 derbyall:derbylang 2007-12-06 22:22:35 *** > 1737 del > < Empty right rows returned = 1 > 1737a1737 > > Empty right rows returned = 0 > Test Failed. > *** End: outerjoin jdk1.6.0_02 derbyall:derbylang 2007-12-06 22:22:43 *** -- 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 (9 issues) Subscriber: derby-dev Key Summary DERBY-3235 Implement the replication stop functionality https://issues.apache.org/jira/browse/DERBY-3235 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-3231 Sorting on COUNT with OR and GROUP BY delivers wrong results. https://issues.apache.org/jira/browse/DERBY-3231 DERBY-3273 convert derbynet/testconnection.java to junit https://issues.apache.org/jira/browse/DERBY-3273 DERBY-3242 ij doesn't understand bracketed comments https://issues.apache.org/jira/browse/DERBY-3242 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 DERBY-3117 Adjust master build script to require the Java 5 compiler to build Derby https://issues.apache.org/jira/browse/DERBY-3117 DERBY-2760 Clean-up issues for UTF8Util.java https://issues.apache.org/jira/browse/DERBY-2760
[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551548 ] Bryan Pendleton commented on DERBY-2998: Dan, do you believe that ROW_NUMBER OVER () is a non-standard use of ROW_NUMBER? > Add support for ROW_NUMBER() window function > > > Key: DERBY-2998 > URL: https://issues.apache.org/jira/browse/DERBY-2998 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Thomas Nielsen >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d2998-4.diff, d2998-4.stat, d2998-5.diff, d2998-5.stat, > d2998-6.diff, d2998-6.stat, d2998-test.diff, d2998-test.stat, > d2998-test2.diff, d2998-test2.stat > > > As part of implementing the overall OLAP Operations features of SQL > (DERBY-581), implement the ROW_NUMBER() window function. > More information about this feature is available at > http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551544 ] Daniel John Debrunner commented on DERBY-2998: -- Thanks Thomas, I agree that the implementation path you are on is good approach, but at some point someone will want to produce a release that is branched off the trunk, we just need to ensure that non-standard use of ROW_NUMBER is not supported. That would either mean disabling ROW_NUMBER in the branch (e.g. 10.4) or not supporting non-standard use in the trunk at any time. Probably any decision can be deferred until closer to the next release, which is due in Feb. Note that the 10.4 wiki page does indicate that ROW_NUMBER() is to be supported in 10.4, from the comments in this issue it seems unlikely a conformant ROW_NUMBER will be finished by then?? > Add support for ROW_NUMBER() window function > > > Key: DERBY-2998 > URL: https://issues.apache.org/jira/browse/DERBY-2998 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Thomas Nielsen >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d2998-4.diff, d2998-4.stat, d2998-5.diff, d2998-5.stat, > d2998-6.diff, d2998-6.stat, d2998-test.diff, d2998-test.stat, > d2998-test2.diff, d2998-test2.stat > > > As part of implementing the overall OLAP Operations features of SQL > (DERBY-581), implement the ROW_NUMBER() window function. > More information about this feature is available at > http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551535 ] Bryan Pendleton commented on DERBY-2998: Perhaps, for this phase of the implementation, we should require OVER (), and the test cases should all use this format. > Add support for ROW_NUMBER() window function > > > Key: DERBY-2998 > URL: https://issues.apache.org/jira/browse/DERBY-2998 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Thomas Nielsen >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d2998-4.diff, d2998-4.stat, d2998-5.diff, d2998-5.stat, > d2998-6.diff, d2998-6.stat, d2998-test.diff, d2998-test.stat, > d2998-test2.diff, d2998-test2.stat > > > As part of implementing the overall OLAP Operations features of SQL > (DERBY-581), implement the ROW_NUMBER() window function. > More information about this feature is available at > http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3274) Developer's Guide has duplicate information on database connections
Developer's Guide has duplicate information on database connections
---
Key: DERBY-3274
URL: https://issues.apache.org/jira/browse/DERBY-3274
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4
Reporter: Kim Haase
The Developer's Guide contains some duplicated information about database
connections and related topics. One glaring example is the short top-level
section "Embedded Derby basics", which comes after a longer section of the same
title under "JDBC applications and Derby basics". The information in the short
section that doesn't duplicate information elsewhere needs to be included in
appropriate places in the long section (and elsewhere as appropriate). The
topics for the short section should then be removed.
Specifically:
For the two introductory topics, the two sentences from
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
embedded basics") should replace the sentence in
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp39409.html (same title),
since they offer more substance.
The first sentence of
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
Derby JDBC driver"), "The Derby driver class name for the embedded environment
is org.apache.derby.jdbc.EmbeddedDriver.", should be moved to
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
driver".
Most of http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html
("Embedded Derby JDBC database connection URL") should be moved to
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html, "Derby JDBC
database connection URL". Also, this text should cross-reference the sections
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp91854.html ("Accessing
databases from the classpath") and
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp24155.html ("Accessing
databases from a jar or zip file"). In
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html itself, the
sentence "For more information about what you can specify with the Derby
connection URL, see "Examples"." is incorrect. I believe this should be a
cross-reference to the section
http://db.apache.org/derby/docs/dev/devguide/rdevdvlp22102.html ("Database
connection examples"). Also, the sentence "For detailed reference about
attributes and values, as well as syntax of the database connection URL, see
the "Derby Database Connection URL Syntax" in the Derby Reference Manual."
refers, I believe, to the wrong section. That particular topic contains only a
couple of sentences and refers back to the Developer's Guide. I think the
sentence should say instead, "For detailed reference about attributes and
values, see "Setting attributes for the database connection URL" in the Derby
Reference Manual." (The syntax is actually covered more fully in the
Developer's Guide than in the Reference Manual.)
The last paragraph of
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
nested connection") should be moved to
http://db.apache.org/derby/docs/dev/devguide/cdevspecial29620.html,
"Database-side JDBC procedures and nested connections". (This topic also has a
couple of minor typographical issues that can be fixed at the same time.)
The example of the use of the jdbc.drivers system property should be moved from
http://db.apache.org/derby/docs/dev/devguide/tdevdvlp38381.html ("Starting
Derby as an embedded database") to
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
driver".
The following sections can then be removed:
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
embedded basics")
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
Derby JDBC driver")
http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html ("Embedded
Derby JDBC database connection URL")
http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
nested connection")
http://db.apache.org/derby/docs/dev/devguide/tdevdvlp38381.html ("Starting
Derby as an embedded database")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3274) Developer's Guide has duplicate information on database connections
[
https://issues.apache.org/jira/browse/DERBY-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim Haase reassigned DERBY-3274:
Assignee: Kim Haase
> Developer's Guide has duplicate information on database connections
> ---
>
> Key: DERBY-3274
> URL: https://issues.apache.org/jira/browse/DERBY-3274
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.3.1.4
>Reporter: Kim Haase
>Assignee: Kim Haase
>
> The Developer's Guide contains some duplicated information about database
> connections and related topics. One glaring example is the short top-level
> section "Embedded Derby basics", which comes after a longer section of the
> same title under "JDBC applications and Derby basics". The information in the
> short section that doesn't duplicate information elsewhere needs to be
> included in appropriate places in the long section (and elsewhere as
> appropriate). The topics for the short section should then be removed.
> Specifically:
> For the two introductory topics, the two sentences from
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
> embedded basics") should replace the sentence in
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp39409.html (same title),
> since they offer more substance.
> The first sentence of
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
> Derby JDBC driver"), "The Derby driver class name for the embedded
> environment is org.apache.derby.jdbc.EmbeddedDriver.", should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
> driver".
> Most of http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html
> ("Embedded Derby JDBC database connection URL") should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html, "Derby JDBC
> database connection URL". Also, this text should cross-reference the sections
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp91854.html ("Accessing
> databases from the classpath") and
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp24155.html ("Accessing
> databases from a jar or zip file"). In
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html itself, the
> sentence "For more information about what you can specify with the Derby
> connection URL, see "Examples"." is incorrect. I believe this should be a
> cross-reference to the section
> http://db.apache.org/derby/docs/dev/devguide/rdevdvlp22102.html ("Database
> connection examples"). Also, the sentence "For detailed reference about
> attributes and values, as well as syntax of the database connection URL, see
> the "Derby Database Connection URL Syntax" in the Derby Reference Manual."
> refers, I believe, to the wrong section. That particular topic contains only
> a couple of sentences and refers back to the Developer's Guide. I think the
> sentence should say instead, "For detailed reference about attributes and
> values, see "Setting attributes for the database connection URL" in the Derby
> Reference Manual." (The syntax is actually covered more fully in the
> Developer's Guide than in the Reference Manual.)
> The last paragraph of
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
> nested connection") should be moved to
> http://db.apache.org/derby/docs/dev/devguide/cdevspecial29620.html,
> "Database-side JDBC procedures and nested connections". (This topic also has
> a couple of minor typographical issues that can be fixed at the same time.)
> The example of the use of the jdbc.drivers system property should be moved
> from http://db.apache.org/derby/docs/dev/devguide/tdevdvlp38381.html
> ("Starting Derby as an embedded database") to
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40653.html, "Derby JDBC
> driver".
> The following sections can then be removed:
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp25174.html ("Derby
> embedded basics")
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40170.html ("Embedded
> Derby JDBC driver")
> http://db.apache.org/derby/docs/dev/devguide/rdevdvlp38881.html ("Embedded
> Derby JDBC database connection URL")
> http://db.apache.org/derby/docs/dev/devguide/cdevdvlp10252.html ("Getting a
> nested connection")
> http://db.apache.org/derby/docs/dev/devguide/tdevdvlp38381.html ("Starting
> Derby as an embedded database")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3268) Reference Manual - PDF version - Explanation column in Sql Expressions section runs off the page - cannot be read
[ https://issues.apache.org/jira/browse/DERBY-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-3268: - Fix Version/s: 10.4.0.0 > Reference Manual - PDF version - Explanation column in Sql Expressions > section runs off the page - cannot be read > -- > > Key: DERBY-3268 > URL: https://issues.apache.org/jira/browse/DERBY-3268 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.4.0.0 >Reporter: Stan Bradbury >Assignee: Kim Haase > Fix For: 10.4.0.0 > > Attachments: DERBY-3268.diff, DERBY-3268.zip > > > NOTE: this may relate to the warnings documented in DERBY-2623. This may be > the same for other tables > Viewing the Reference Guide: SQL Expressions section in the PDF version > (HTML is OK) > the tables beginning with "Table 2. Table of general expressions" the > second column runs off the page. > Tables 3, 4 and 5 are also truncated like this. > Table 6 appears to be formatted well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3260) NullPointerException caused by race condition in GenericActivationHolder
[ https://issues.apache.org/jira/browse/DERBY-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551525 ] Thomas Nielsen commented on DERBY-3260: --- Robert, Could you please post a proper patch with your proposed changes for others to test and review as well? It would also be good to assign this issue to yourself to indicate that you are working on it. > NullPointerException caused by race condition in GenericActivationHolder > > > Key: DERBY-3260 > URL: https://issues.apache.org/jira/browse/DERBY-3260 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, > 10.2.2.0, 10.3.1.4 >Reporter: Robert Yokota >Priority: Blocker > > I have a stress test using Derby 10.3.1.4 which is executing the same > PreparedStatement using multiple threads concurrently and I consistently get > the following NPE after several hours of running: > 2007-12-07 00:48:10.914 GMT Thread[pool-5-thread-25,5,main] (XID = 1219661), > (SESSIONID = 377), (DATABASE = /usr/ironhide/var/db/opera/derby), (DRDAID = > null), Failed Statement is: select rdbmsvaria0_.GUID_AND_INDEX as GUID1_3_0_, > rdbmsvaria0_.VALUE2 as VALUE2_3_0_, rdbmsvaria0_.HOLDER_GUID as HOLDER3_3_0_, > rdbmsvaria0_.VALUE_TYPE as VALUE4_3_0_, rdbmsvaria0_.VALUE_GUID as > VALUE5_3_0_, rdbmsvaria0_.DELETED as DELETED3_0_ from VARIABLE rdbmsvaria0_ > where rdbmsvaria0_.GUID_AND_INDEX=? with 1 parameters begin parameter #1: > 9C202AB9E8356288A9320C9C383A4D2F-11 :end parameter > java.lang.NullPointerException > at > org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:271) > at > org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:368) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1203) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:275) > at > org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186) > at org.hibernate.loader.Loader.getResultSet(Loader.java:1787) > at org.hibernate.loader.Loader.doQuery(Loader.java:674) > at > org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) > at org.hibernate.loader.Loader.loadEntity(Loader.java:1860) > at > org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48) > at > org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42) > at > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3044) > at > org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:395) > at > org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375) > at > org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139) > at > org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:179) > at > org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878) > at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815) > at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808) > at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301) > at $Proxy41.get(Unknown Source) > at > com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getRdbmsVariable(RdbmsContextHolder.java:108) > at > com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getVariable(RdbmsContextHolder.java:94) > at com.approuter.maestro.vm.Frame.getParameter(Frame.java:218) > at com.approuter.maestro.vm.Task.getParameter(Task.java:1267) > at > com.approuter.maestro.vm.CallContextImpl.setOutputParameter(CallContextImpl.java:195) > at > com.approuter.maestro.vm.CallContextImpl.getOutputParameterWriter(CallContextImpl.java:264) > at > com.approuter.maestro.sdk.mpi.DynamicExecutableActivity$3$1.getWriter(DynamicExecutableActivity.java:249) > at > com.approuter.module.xml.XmlSerializeTextActivity$XmlSeriali
[jira] Resolved: (DERBY-3268) Reference Manual - PDF version - Explanation column in Sql Expressions section runs off the page - cannot be read
[ https://issues.apache.org/jira/browse/DERBY-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase resolved DERBY-3268. -- Resolution: Fixed Thanks very much, Dyre and Stan. > Reference Manual - PDF version - Explanation column in Sql Expressions > section runs off the page - cannot be read > -- > > Key: DERBY-3268 > URL: https://issues.apache.org/jira/browse/DERBY-3268 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.4.0.0 >Reporter: Stan Bradbury >Assignee: Kim Haase > Attachments: DERBY-3268.diff, DERBY-3268.zip > > > NOTE: this may relate to the warnings documented in DERBY-2623. This may be > the same for other tables > Viewing the Reference Guide: SQL Expressions section in the PDF version > (HTML is OK) > the tables beginning with "Table 2. Table of general expressions" the > second column runs off the page. > Tables 3, 4 and 5 are also truncated like this. > Table 6 appears to be formatted well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3244) NullPointerException in ....B2IRowLocking3.searchLeftAndLockPreviousKey
[ https://issues.apache.org/jira/browse/DERBY-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551507 ] Ole Solberg commented on DERBY-3244: I did 100 storemore test runs on 603375 without seeing the failure. (On 603319 it hit after 11 runs.) > NullPointerException in B2IRowLocking3.searchLeftAndLockPreviousKey > --- > > Key: DERBY-3244 > URL: https://issues.apache.org/jira/browse/DERBY-3244 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Store >Affects Versions: 10.3.2.1, 10.4.0.0 > Environment: All ? >Reporter: Ole Solberg >Assignee: Mike Matrigali > > The last week(48) we have seen a large number of this failure. > It was categorized as DERBY-2589 but these instances all have the NPE. > Exception while trying to insert row number: 52 > ERROR XJ001: Java exception: ': java.lang.NullPointerException'. > java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.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.executeStatement(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown > Source) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.createAndLoadTable(OnlineCompressTest.java:140) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.deleteAllRows(OnlineCompressTest.java:494) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.test1(OnlineCompressTest.java:913) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.testList(OnlineCompressTest.java:1500) > at > org.apache.derbyTesting.functionTests.tests.store.OnlineCompressTest.main(OnlineCompressTest.java:1520) > Caused by: java.lang.NullPointerException > at > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.searchLeftAndLockPreviousKey(Unknown > Source) > at > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockNonScanPreviousRow(Unknown > Source) > at > org.apache.derby.impl.store.access.btree.BTreeController.doIns(Unknown Source) > at > org.apache.derby.impl.store.access.btree.BTreeController.insert(Unknown > Source) > at > org.apache.derby.impl.store.access.btree.index.B2IController.insert(Unknown > Source) > at > org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown > Source) > at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown > Source) > at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown Source) > at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown > Source) > at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown > Source) > at > org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown > Source) > at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown > Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > ... 8 more > The error statistics shows the occurrences: > (http://dbtg.thresher.com/derby/test/stats_today.html / > http://dbtg.thresher.com/derby/test/stats_newest.html ) > http://dbtg.thresher.com/derby/test/statistics/2589_48.html : > JIRA: 2589, Week: 48 600335-598009 > 598009 Daily jvm1.4 vista > 598009 Daily jvm1.6 lin > 598341 Daily jvm1.6 solN+1 > 598341 Daily jvm1.6 sparc > 598354 10.3Branch jvm1.5 lin > 598376 trunk16 jvmAll JDK16Jvm1.5SunOS-5.10_i86pc-i386 > 598692 Daily jvm1.6 sol > 598729 trunk16 jvmAll JDK16Jvm1.6SunOS-5.10_i86pc-i386 > 599062 Daily jvm1.5 lin > 599088 trunk15 jvm1.5 SunOS-5.10_i86pc-i386 > 599088 trunk15 jvm1.5 SunOS-5.10_sun4u-sparc > 599088 trunk16 jvmAll JDK16Jvm1.5SunOS-5.10_i86pc-i386 > 600335 Daily jvm1.4 lin > Mon Dec 3 09:36:11 CET 2007 > http://dbtg.thresher.com/derby/test/statistics/2589_47.html seems to be the > first occurence: > JIRA: 2589, Week: 47 597885-597885 > 597885 Daily jvm1.6 lin > Mon Dec 3 09:36:13 CET 2007 > All are seen on trunk exc
[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-tabpanel#action_12551503 ] Øystein Grøvlen commented on DERBY-3235: Narayanan, the patch does not apply cleanly to head of trunk anymore. Could you please generate a new version of the patch? > Implement the replication stop functionality > > > Key: DERBY-3235 > URL: https://issues.apache.org/jira/browse/DERBY-3235 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: StopImplementation_v1_NotForCommit.diff, > StopImplementation_v1_NotForCommit.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-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-tabpanel#action_12551496 ] James Alan Shepherd commented on DERBY-3221: ooh, 10.3.2.1 is out: Bug still present :-( > "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 > Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0) >Reporter: Tim Halloran > > 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-3268) Reference Manual - PDF version - Explanation column in Sql Expressions section runs off the page - cannot be read
[ https://issues.apache.org/jira/browse/DERBY-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3268: -- Derby Info: (was: [Patch Available]) Committed revision 603911. > Reference Manual - PDF version - Explanation column in Sql Expressions > section runs off the page - cannot be read > -- > > Key: DERBY-3268 > URL: https://issues.apache.org/jira/browse/DERBY-3268 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.4.0.0 >Reporter: Stan Bradbury >Assignee: Kim Haase > Attachments: DERBY-3268.diff, DERBY-3268.zip > > > NOTE: this may relate to the warnings documented in DERBY-2623. This may be > the same for other tables > Viewing the Reference Guide: SQL Expressions section in the PDF version > (HTML is OK) > the tables beginning with "Table 2. Table of general expressions" the > second column runs off the page. > Tables 3, 4 and 5 are also truncated like this. > Table 6 appears to be formatted well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3261) 'Empty right rows returned = 0' expected '... = 1' in lang/outerjoin.sql
[ https://issues.apache.org/jira/browse/DERBY-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551453 ] Ole Solberg commented on DERBY-3261: Fixed in trunk tinderbox run on svn 603823: http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-603823.html > 'Empty right rows returned = 0' expected '... = 1' in lang/outerjoin.sql > > > Key: DERBY-3261 > URL: https://issues.apache.org/jira/browse/DERBY-3261 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: OS: Solaris 10 6/06 s10x_u2wos_09a X86 64bits - SunOS > 5.10 Generic_118855-14 > JVM: Sun Microsystems Inc. 1.6.0_02-b05 >Reporter: Ole Solberg >Assignee: Mamta A. Satoor >Priority: Minor > > See > http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/601833-derbyall_diff.txt > Failure Details: > * Diff file derbyall/derbylang/outerjoin.diff > *** Start: outerjoin jdk1.6.0_02 derbyall:derbylang 2007-12-06 22:22:35 *** > 1737 del > < Empty right rows returned = 1 > 1737a1737 > > Empty right rows returned = 0 > Test Failed. > *** End: outerjoin jdk1.6.0_02 derbyall:derbylang 2007-12-06 22:22:43 *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2348) testProtocol(org.apache.derbyTesting.functionTests.tests.derbynet.NetHarnessJavaTest)j failed
[ https://issues.apache.org/jira/browse/DERBY-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre reassigned DERBY-2348: -- Assignee: (was: Andrew McIntyre) > testProtocol(org.apache.derbyTesting.functionTests.tests.derbynet.NetHarnessJavaTest)j > failed > -- > > Key: DERBY-2348 > URL: https://issues.apache.org/jira/browse/DERBY-2348 > Project: Derby > Issue Type: Test > Components: Regression Test Failure >Affects Versions: 10.3.1.4 > Environment: This test failed on ibm142/ibm15. >Reporter: Suresh Thalamati > > 3) > testProtocol(org.apache.derbyTesting.functionTests.tests.derbynet.NetHarnessJavaTest)junit.framework.ComparisonFailure: > Output at line 26 expected:<..> but was:<...9 SECMEC=...> > at > org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) > at > org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
[ https://issues.apache.org/jira/browse/DERBY-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-1651: --- Fix Version/s: (was: 10.2.3.0) Unsetting fix version, no movement for over a year. > Develop a mechanism to migrate mySQL databases to Derby. Migration tool > should include both schema and data migration options. > -- > > Key: DERBY-1651 > URL: https://issues.apache.org/jira/browse/DERBY-1651 > Project: Derby > Issue Type: New Feature > Components: Tools > Environment: All platforms >Reporter: Ramin Moazeni >Assignee: Ramin Moazeni > Attachments: DBMigration.diff, MigrationTool-MySQLtoDerby.zip > > > Develop a mechanism to migration databases created by other database engines > to Derby. While my current interest is to migrate mySQL databases to Derby, > the tool could be developed in a way to extend this mechanism to allow > migration from other database engines in the future. > More details of proposed functionality and implementation strategy can be > found at: > http://wiki.apache.org/db-derby/MysqlDerbyMigration > The plan is to develop and submit patches incrementally. First patch supports > migration of tables and views from mySQL database to Derby. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2484) Convert syscat.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre closed DERBY-2484. -- Resolution: Fixed Fix Version/s: (was: 10.3.1.4) 10.4.0.0 Assignee: Andrew McIntyre Changed fixture testNoUserDDLOnSystemTables to use assertStatementError with revision 603855. > Convert syscat.sql to junit > --- > > Key: DERBY-2484 > URL: https://issues.apache.org/jira/browse/DERBY-2484 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.1.4 >Reporter: Andrew McIntyre >Assignee: Andrew McIntyre >Priority: Minor > Fix For: 10.4.0.0 > > Attachments: derby-2484-v1.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2658) Convert jdbcapi/parameterMetaDataJdbc30.java to JUnit
[ https://issues.apache.org/jira/browse/DERBY-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-2658: --- Fix Version/s: (was: 10.3.1.4) 10.3.2.2 Should rev 572662 be backported to the 10.3 branch so we can close this issue again? > Convert jdbcapi/parameterMetaDataJdbc30.java to JUnit > - > > Key: DERBY-2658 > URL: https://issues.apache.org/jira/browse/DERBY-2658 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.1.4 >Reporter: Ramin Moazeni >Assignee: Ramin Moazeni > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: DERBY-2658.diff, DERBY-2658.diff-060807, > DERBY-2658.diff-061307, DERBY-2658.stat-060807, DERBY-2658_061807.diff, > DERBY-2658_061807.stat, DERBY-2658v4.diff > > > Convert jdbcapi/parameterMetaDataJdbc30.java to JUnit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-2953: --- Fix Version/s: (was: 10.3.1.4) > Dump the information about rollbacks of the global transaction (introduced in > DERBY-2220 and DERBY-2432) to derby.log > - > > Key: DERBY-2953 > URL: https://issues.apache.org/jira/browse/DERBY-2953 > Project: Derby > Issue Type: Improvement > Components: JDBC >Reporter: Julius Stroffek >Assignee: Julius Stroffek > Fix For: 10.4.0.0 > > Attachments: d2953.diff, d2953.stat > > > When the global transaction is going to be rolled back that information > should be dumped to derby.log so that users can find out what happened. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2982) Track changes during my tenure as 10.3 release manager
[ https://issues.apache.org/jira/browse/DERBY-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre closed DERBY-2982. -- Resolution: Fixed 10.3.1.4 released. Closing. > Track changes during my tenure as 10.3 release manager > -- > > Key: DERBY-2982 > URL: https://issues.apache.org/jira/browse/DERBY-2982 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.3.1.4 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.3.1.4 > > Attachments: derby-2982-01-releaseNotes.diff, > derby-2982-02-releaseNotes.diff, derby-2982-03-releaseNotes.diff, > derby-2982-04-website.diff, derby-2982-05-htmlComments.diff, > derby-2982-06-doap.diff, derby-2982-07-status.diff, > derby-2982-08-docsPage.diff, derby-2982-09-news.diff, > derby-2982-11-scrub10.2.diff, derby-2982-12-scrub10.2redux.diff, > derby-2982-13-brokenLinks-ab.diff, derby-2982-13-brokenLinks-ac.diff, > derby-2982-13-brokenLinks.diff, RELEASE-NOTES.html, RELEASE-NOTES.html > > > Place to record changes made to support 10.3 release candidates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2994) Open cursor is not functioning as expected when used with Rename Table
[
https://issues.apache.org/jira/browse/DERBY-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew McIntyre closed DERBY-2994.
--
Resolution: Invalid
No further comments, closing as invalid.
> Open cursor is not functioning as expected when used with Rename Table
> ---
>
> Key: DERBY-2994
> URL: https://issues.apache.org/jira/browse/DERBY-2994
> Project: Derby
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 10.3.1.4
>Reporter: Ravinder Reddy
> Fix For: 10.3.1.4
>
>
> In the context of following scenario
> public void testRenameOpenCursoredTable() throws SQLException {
> Statement s = createStatement(ResultSet.TYPE_FORWARD_ONLY ,
> ResultSet.CONCUR_UPDATABLE);
> assertUpdateCount(s , 0 , "create table t2(c21 int not null primary
> key)");
> assertUpdateCount(s , 1 , "insert into t2 values(21)");
> assertUpdateCount(s , 1 , "insert into t2 values(22)");
> ResultSet rs = s.executeQuery("select * from t2");
> rs.next();
> assertStatementError("X0X95" , s , "rename table t2 to fake");
> }
> I am expecting an open cursor and asserting the last Statement to throw
> an Exception(with SQLState "X0X95") .But the cursor was not opened at the
> last statement as the statement was executed successfully without any
> Exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
