Nabble - Apache Derby Developers

[jira] Updated: (DERBY-4153) Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist

2009-11-24T17:46:39Z

> Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4153
> URL: https://issues.apache.org/jira/browse/DERBY-4153
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.6.0.0
> Reporter: Kathey Marsden
> Assignee: Bryan Pendleton
> Priority: Minor
> Attachments: docs.diff, docs.diff, docs.diff, radminconfigdb2jdrdatracedirectory.html, radminconfigdb2jdrdatracedirectory.html, radminconfigdb2jdrdatracedirectory.html, tadminadv804410.html, tadminadv804410.html, tadminadv804410.html
>
>
> Starting with 10.5, Network server will attempt to create the trace directory (and any parent directories) if they do not exist. This will require that the derbynet.jar permit verification of the existence of the named trace directory and all necessary parent directories. For each directory created, the policy will require
> permission java.io.FilePermission "<directory>", "read,write"
> and the trace directory will require
> permission java.io.FilePermission "<trace directory>${/}/-", "write"

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4153) Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist

2009-11-24T15:53:39Z

[ https://issues.apache.org/jira/browse/DERBY-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782247#action_12782247 ]

Dag H. Wanvik commented on DERBY-4153:
--------------------------------------

I wonder if there is a superfluous "/" in this line:

permission java.io.FilePermission "<tracedirectory>${/}/-", "write";

Isn't ${/}- enough? "${/}", is a shortcut for "${file.separator}", so is another "/" needed/correct here?

> Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4153
> URL: https://issues.apache.org/jira/browse/DERBY-4153
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.6.0.0
> Reporter: Kathey Marsden
> Assignee: Bryan Pendleton
> Priority: Minor
> Attachments: docs.diff, docs.diff, radminconfigdb2jdrdatracedirectory.html, radminconfigdb2jdrdatracedirectory.html, tadminadv804410.html, tadminadv804410.html
>
>
> Starting with 10.5, Network server will attempt to create the trace directory (and any parent directories) if they do not exist. This will require that the derbynet.jar permit verification of the existence of the named trace directory and all necessary parent directories. For each directory created, the policy will require
> permission java.io.FilePermission "<directory>", "read,write"
> and the trace directory will require
> permission java.io.FilePermission "<trace directory>${/}/-", "write"

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-4433) Cannot insert from EXCEPT/INTERSECT when target table has more columns than the source

2009-11-24T14:57:39Z

[ https://issues.apache.org/jira/browse/DERBY-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782200#action_12782200 ]

Dag H. Wanvik edited comment on DERBY-4433 at 11/24/09 10:57 PM:
-----------------------------------------------------------------

Adding the following line to SetOperatorNode#enhanceRCLForInsert just before the call to generateProjectRestrictForInsert made the above case work:

resultColumns.resetVirtualColumnIds();

Cf. the following lines in SetOperatorNode#enhanceRCLForInsert:

:
ResultColumnList newResultCols = getRCLForInsert(target, colMap);
[ resultColumns.resetVirtualColumnIds(); ]
return generateProjectRestrictForInsert(target, colMap);
:
A priori in the example, there is one column in the source result set, so that column number has virtualColumnNumber 1.
However, getRCLForInsert reuses the column object for the new ResultColumnList, so the virtualColumnNumber gets set to 8 when enhancing. But in the original source result set this is wrong, so this line in generateProjectRestrictForInsert returns a null:

oldResultColumn = resultColumns.getResultColumn(colMap[index]+1);

since the virtualColumnNumber does not match the columns position, cf the logic in ResultColumnList#getResultColumn.
Resetting the viirtual column ids bring it back in shape, but it is not the right solution, since the numbers would then be wacky for the PRN's RCL. I think a copy of the RC should be taken instead, cf. your observation above that the tree looks weird.

was (Author: dagw):
Adding the following line to SetOperatorNode#enhanceRCLForInsert just before the call to generateProjectRestrictForInsert made the above case work:

resultColumns.resetVirtualColumnIds();

Cf. the following lines in SetOperatorNode#enhanceRCLForInsert:

:
ResultColumnList newResultCols = getRCLForInsert(target, colMap);
resultColumns.treePrint();
[ resultColumns.resetVirtualColumnIds(); ]
return generateProjectRestrictForInsert(target, colMap);
:
A priori in the example, there is one column in the source result set, so that column number has virtualColumnNumber 1.
However, getRCLForInsert reuses the column object for the new ResultColumnList, so the virtualColumnNumber gets set to 8 when enhancing. But in the original source result set this is wrong, so this line in generateProjectRestrictForInsert returns a null:

oldResultColumn = resultColumns.getResultColumn(colMap[index]+1);

since the virtualColumnNumber does not match the columns position, cf the logic in ResultColumnList#getResultColumn.
Resetting the viirtual column ids bring it back in shape, but it is not the right solution, since the numbers would then be wacky for the PRN's RCL. I think a copy of the RC should be taken instead, cf. your observation above that the tree looks weird.

> Cannot insert from EXCEPT/INTERSECT when target table has more columns than the source
> --------------------------------------------------------------------------------------
>
> Key: DERBY-4433
> URL: https://issues.apache.org/jira/browse/DERBY-4433
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: prn.diff, prn2.diff, prn3.diff
>
>
> If an INSERT statement takes the rows to insert from an EXCEPT query or an INTERSECT query, the statement fails with "Column position 'X' out of range" if the target table contains more columns than the result returned from EXCEPT or INTERSECT.
> Example:
> ij> create table t (x int, y int);
> 0 rows inserted/updated/deleted
> ij> insert into t(x) select x from t except select x from t;
> ERROR 42X77: Column position '2' is out of range for the query expression.
> ij> insert into t(x) select x from t intersect select x from t;
> ERROR 42X77: Column position '2' is out of range for the query expression.
> The corresponding UNION query works:
> ij> insert into t(x) select x from t union select x from t;
> 0 rows inserted/updated/deleted

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4433) Cannot insert from EXCEPT/INTERSECT when target table has more columns than the source

2009-11-24T14:55:39Z

[ https://issues.apache.org/jira/browse/DERBY-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782217#action_12782217 ]

Dag H. Wanvik commented on DERBY-4433:
--------------------------------------

Right, this seems to be handled correctly in derby-4442-1a; that patch also works together with derby-4451d, good, running regressions for that combination now.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4433) Cannot insert from EXCEPT/INTERSECT when target table has more columns than the source

2009-11-24T14:10:39Z

[ https://issues.apache.org/jira/browse/DERBY-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782200#action_12782200 ]

Dag H. Wanvik commented on DERBY-4433:
--------------------------------------

Adding the following line to SetOperatorNode#enhanceRCLForInsert just before the call to generateProjectRestrictForInsert made the above case work:

resultColumns.resetVirtualColumnIds();

Cf. the following lines in SetOperatorNode#enhanceRCLForInsert:

:
ResultColumnList newResultCols = getRCLForInsert(target, colMap);
resultColumns.treePrint();
[ resultColumns.resetVirtualColumnIds(); ]
return generateProjectRestrictForInsert(target, colMap);
:
A priori in the example, there is one column in the source result set, so that column number has virtualColumnNumber 1.
However, getRCLForInsert reuses the column object for the new ResultColumnList, so the virtualColumnNumber gets set to 8 when enhancing. But in the original source result set this is wrong, so this line in generateProjectRestrictForInsert returns a null:

oldResultColumn = resultColumns.getResultColumn(colMap[index]+1);

since the virtualColumnNumber does not match the columns position, cf the logic in ResultColumnList#getResultColumn.
Resetting the viirtual column ids bring it back in shape, but it is not the right solution, since the numbers would then be wacky for the PRN's RCL. I think a copy of the RC should be taken instead, cf. your observation above that the tree looks weird.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-2284) OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change once written: was 0, now 80

2009-11-24T12:17:39Z

[ https://issues.apache.org/jira/browse/DERBY-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen closed DERBY-2284.
-------------------------------------

Resolution: Duplicate

Closing as duplicate of DERBY-3347. Please reopen if it happens again.

> OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change once written: was 0, now 80
> ---------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2284
> URL: https://issues.apache.org/jira/browse/DERBY-2284
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.3.1.4
> Environment: Windows 2000, IBM JDK 1.5
> Reporter: Andrew McIntyre
> Attachments: derby.log, OnlineBackupTest1.out
>
>
> Saw this error in the nightlies last week, seems to be intermittant, filing this for tracking purposes:
> *** Start: OnlineBackupTest1 jdk1.5.0 storeall:storemore 2007-01-23 02:37:22 ***
> 5 del
> < database shutdown properly
> 6 del
> < Restored From the Backup
> 7 del
> < Consistency Check is Done
> 8 del
> < database shutdown properly
> 9 del
> < End Online Backup Test1
> 9 add
> > ERROR XJ001: Java exception: ': org.apache.derby.iapi.services.context.ShutdownException'.
> > org.apache.derby.iapi.services.context.ShutdownException:
> > ERROR 08003: No current connection.
> > java.sql.SQLException: No current connection.
> > ERROR XSDB3: Container information cannot change once written: was 0, now 80
> > ERROR XSDB3: Container information cannot change once written: was 0, now 80
> > at org.apache.derby.impl.store.raw.log.LogToFile.checkpException in thread "main" java.lang.Exception: BACKUP FAILED:Container information cannot change once written: was 0, now 80
> > oint(Unknown Source)
> Test Failed.
> *** End: OnlineBackupTest1 jdk1.5.0 storeall:storemore 2007-01-23 02:38:23 ***

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4433) Cannot insert from EXCEPT/INTERSECT when target table has more columns than the source

2009-11-24T12:13:39Z

[ https://issues.apache.org/jira/browse/DERBY-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782135#action_12782135 ]

Knut Anders Hatlen commented on DERBY-4433:
-------------------------------------------

That's what I see too now. Don't know what has changed, or if I misread the test results.

Anyways, the 1a patch attached to DERBY-4442 (which is based on the prn3) does not cause any NPE in union.sql.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4453) OnlineBackupTest1 nightly test failed with "java.io.EOFException: Reached end of file while attempting to read a whole page."

2009-11-24T12:11:39Z

[ https://issues.apache.org/jira/browse/DERBY-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-4453:
----------------------------------

is there anything in the top path starting at extinout/onlinebackuptest1? From the complete derby.log that I got from the above link I can tell that the failure occurs while
trying to boot an online backup made by the onlinebackuptest1. It looks like this backup
goes to extinout/onlinebackuptest1. If you still have this and can post it, it may be
useful.

Here is an inline version of the derby.log failure:

----------------------------------------------------------------
2009-11-20 23:13:19.658 GMT:
Booting Derby version The Apache Software Foundation - Apache Derby - 10.6.0.0 alpha - (882732): instance a816c00e-0125-13df-009f-ffffe0436f6b
on database directory /export/home/tmp/os136789/testingDerbyTinderBox/SunOS-5.10_i86pc-i386/derbyall/derbyall/storeall/storemore/OnlineBackupTest1/wom
bat

Database Class Loader started - derby.database.classpath=''

2009-11-20 23:14:25.309 GMT:
Shutting down instance a816c00e-0125-13df-009f-ffffe0436f6b
----------------------------------------------------------------
----------------------------------------------------------------
2009-11-20 23:14:25.681 GMT:
Booting Derby version The Apache Software Foundation - Apache Derby - 10.6.0.0 alpha - (882732): instance 82d8ac35-0125-13df-009f-ffffe0436f6b
on database directory /export/home/tmp/os136789/testingDerbyTinderBox/SunOS-5.10_i86pc-i386/derbyall/derbyall/storeall/storemore/OnlineBackupTest1/wom
bat

------------ BEGIN SHUTDOWN ERROR STACK -------------

ERROR XSLA7: Cannot redo operation null in the log.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.store.raw.log.FileLogger.redo(Unknown Source)
at org.apache.derby.impl.store.raw.log.LogToFile.recover(Unknown Source)
at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source)
at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
at org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackup.restoreFromBackup(OnlineBackup.java:176)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest1.runTest(OnlineBackupTest1.java:155)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest1.main(OnlineBackupTest1.java:52)
Caused by: ERROR XSDG0: Page Page(3,Container(0, 40768)) could not be read from disk.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.readPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown Source)
at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown Source)
at org.apache.derby.impl.store.raw.data.FileContainer.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.BaseContainer.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.PageBasicOperation.findpage(Unknown Source)
at org.apache.derby.impl.store.raw.data.PageBasicOperation.needsRedo(Unknown Source)
... 34 more
Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page.
at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(Unknown Source)
at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(Unknown Source)
at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(Unknown Source)
... 42 more
============= begin nested exception, level (1) ===========
ERROR XSDG0: Page Page(3,Container(0, 40768)) could not be read from disk.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.readPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown Source)
at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown Source)
at org.apache.derby.impl.store.raw.data.FileContainer.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.BaseContainer.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.PageBasicOperation.findpage(Unknown Source)
at org.apache.derby.impl.store.raw.data.PageBasicOperation.needsRedo(Unknown Source)
at org.apache.derby.impl.store.raw.log.FileLogger.redo(Unknown Source)
at org.apache.derby.impl.store.raw.log.LogToFile.recover(Unknown Source)
at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source)
at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
at org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackup.restoreFromBackup(OnlineBackup.java:176)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest1.runTest(OnlineBackupTest1.java:155)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest1.main(OnlineBackupTest1.java:52)
Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page.
at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(Unknown Source)
at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(Unknown Source)
at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(Unknown Source)
... 42 more
============= end nested exception, level (1) ===========
============= begin nested exception, level (2) ===========
java.io.EOFException: Reached end of file while attempting to read a whole page.
at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(Unknown Source)
at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(Unknown Source)
at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.readPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown Source)
at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown Source)
at org.apache.derby.impl.store.raw.data.FileContainer.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.BaseContainer.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getAnyPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.PageBasicOperation.findpage(Unknown Source)
at org.apache.derby.impl.store.raw.data.PageBasicOperation.needsRedo(Unknown Source)
at org.apache.derby.impl.store.raw.log.FileLogger.redo(Unknown Source)
at org.apache.derby.impl.store.raw.log.LogToFile.recover(Unknown Source)
at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source)
at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
at org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackup.restoreFromBackup(OnlineBackup.java:176)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest1.runTest(OnlineBackupTest1.java:155)
at org.apache.derbyTesting.functionTests.tests.store.OnlineBackupTest1.main(OnlineBackupTest1.java:52)
============= end nested exception, level (2) ===========

------------ END SHUTDOWN ERROR STACK -------------

> OnlineBackupTest1 nightly test failed with "java.io.EOFException: Reached end of file while attempting to read a whole page."
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4453
> URL: https://issues.apache.org/jira/browse/DERBY-4453
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.6.0.0
> Environment: ------------------ Java Information ------------------
> Java Version: 1.6.0_15
> Java Vendor: Sun Microsystems Inc.
> Java home: /usr/local/java/jdk1.6.0_15/jre
> Java classpath: /home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derby.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyclient.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbytools.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbynet.jar:/home/os136789/Apache/TinderBox_Derby/db2jcc/lib/db2jcc.jar:/home/os136789/Apache/TinderBox_Derby/db2jcc/lib/db2jcc_license_c.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyTesting.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyrun.jar:/home/os136789/Apache/TinderBox_Derby/trunk/tools/java/jakarta-oro-2.0.8.jar:/home/os136789/Apache/TinderBox_Derby/trunk/tools/java/junit.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_de_DE.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_es.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_fr.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_it.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_ja_JP.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_ko_KR.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_pt_BR.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_zh_CN.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_zh_TW.jar:/usr/local/share/java/xalan/serializer.jar:/usr/local/share/java/xalan/xalan.jar:/usr/local/share/java/xalan/xercesImpl.jar:/usr/local/share/java/xalan/xml-apis.jar:/usr/local/share/java/xalan/xsltc.jar
> OS name: SunOS
> OS architecture: x86
> OS version: 5.10
> Java user name: os136789
> Java user home: /home/os136789
> Java user dir: /export/home/tmp/os136789/testingDerbyTinderBox/SunOS-5.10_i86pc-i386/derbyall
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derby.jar] 10.6.0.0 alpha - (882732)
> [/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbytools.jar] 10.6.0.0 alpha - (882732)
> [/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbynet.jar] 10.6.0.0 alpha - (882732)
> [/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyclient.jar] 10.6.0.0 alpha - (882732)
> [/home/os136789/Apache/TinderBox_Derby/db2jcc/lib/db2jcc.jar] 2.4 - (17)
> [/home/os136789/Apache/TinderBox_Derby/db2jcc/lib/db2jcc_license_c.jar] 2.4 - (17)
> Reporter: Mike Matrigali
>
> Online backup test failed in nightly tinderbox run:
> http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/882732-derbyall_diff.txt
> Failure Details:
> ********* Diff file derbyall/derbynetmats/DerbyNet/jdbcapi/derbyStress.diff
> *** Start: derbyStress jdk1.6.0_15 DerbyNet derbynetmats:jdbcapi 2009-11-21 00:07:40 ***
> Test skipped: listed in DerbyNet.exclude file, skipping test: jdbcapi/derbyStress.java
> *** End: derbyStress jdk1.6.0_15 DerbyNet derbynetmats:jdbcapi 2009-11-21 00:07:40 ***
> ********* Diff file derbyall/storeall/storemore/OnlineBackupTest1.diff
> *** Start: OnlineBackupTest1 jdk1.6.0_15 storeall:storemore 2009-11-21 00:13:18 ***
> 6 del
> < Restored From the Backup
> 7 del
> < Consistency Check is Done
> 8 del
> < database shutdown properly
> 9 del
> < End Online Backup Test1
> 9 add
> > ERROR XJ040: Failed to start database 'wombat', see the next exception for details.
> > ERROR XSDG0: Page Page(3,Container(0, 40768)) could not be read from disk.
> > java.sql.SQLException: Failed to start database 'wombat', see the next exception for details.
> > Caused by: java.sql.SQLException: Failed to start database 'wombat', see the next exception for details.
> > ... 16 more
> > Caused by: java.sql.SQLException: Page Page(3,Container(0, 40768)) could not be read from disk.
> > ... 13 more
> > Caused by: ERROR XSDG0: Page Page(3,Container(0, 40768)) could not be read from disk.
> > ... 13 more
> > Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page.
> > ... 42 more
> Test Failed.
> *** End: OnlineBackupTest1 jdk1.6.0_15 storeall:storemore 2009-11-21 00:14:25 ***
> ********* Diff file derbyall/derbynetclientmats/DerbyNetClient/encodingTests/TestEnc.diff
> *** Start: TestEnc jdk1.6.0_15 DerbyNetClient derbynetclientmats:encodingTests 2009-11-21 00:20:39 ***
> derbyTesting.encoding can only be used with jdk15, skipping test
> *** End: TestEnc jdk1.6.0_15 DerbyNetClient derbynetclientmats:encodingTests 2009-11-21 00:20:39 ***
> ------------------------------------------------------

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Fwd: [jira] Account signup

2009-11-24T12:07:02Z

Jayaram Subramanian wrote:

> Could i please be added under the developer group.
>
> ---------- Forwarded message ----------
> From: <jira@... <mailto:jira@...>>
> Date: Mon, Nov 23, 2009 at 10:48 PM
> Subject: [jira] Account signup
> To: rsjay1976@... <mailto:rsjay1976@...>
>
>
> You have signed up for a JIRA account at:
>
> https://issues.apache.org/jira
>
> Here are the details of your account:
> ---------------------------------------------------------------------
> Username: rsjay1976

Welcome Jayaram!
I unfortunately don't have permission to add you to the Jira developers
group but I am sure someone who does will add you soon. Meanwhile set up
your build and test environment and let us know if you have any
questions. Ross posted some rough outline information on the Mentoring
Programme (since Ross put up the page, he gets to spell it) and I hope
to post the application template soon. http://community.apache.org/

Kathey

[jira] Commented: (DERBY-4433) Cannot insert from EXCEPT/INTERSECT when target table has more columns than the source

2009-11-24T11:55:39Z

[ https://issues.apache.org/jira/browse/DERBY-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782129#action_12782129 ]

Dag H. Wanvik commented on DERBY-4433:
--------------------------------------

Tried prn3, but I got another error in the union script:

insert into insert_test (vc30) select vc10 from t1 union select c30 from t2;
ERROR XJ001: Java exception: ': java.lang.NullPointerException'

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4153) Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist

2009-11-24T10:26:39Z

> Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4153
> URL: https://issues.apache.org/jira/browse/DERBY-4153
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.6.0.0
> Reporter: Kathey Marsden
> Assignee: Bryan Pendleton
> Priority: Minor
> Attachments: docs.diff, docs.diff, radminconfigdb2jdrdatracedirectory.html, radminconfigdb2jdrdatracedirectory.html, tadminadv804410.html, tadminadv804410.html
>
>
> Starting with 10.5, Network server will attempt to create the trace directory (and any parent directories) if they do not exist. This will require that the derbynet.jar permit verification of the existence of the named trace directory and all necessary parent directories. For each directory created, the policy will require
> permission java.io.FilePermission "<directory>", "read,write"
> and the trace directory will require
> permission java.io.FilePermission "<trace directory>${/}/-", "write"

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4451) ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order

2009-11-24T10:14:39Z

> ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4451
> URL: https://issues.apache.org/jira/browse/DERBY-4451
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Attachments: derby-4451.diff, derby-4451.stat, derby-4451b.diff, derby-4451b.stat, derby-4451c.diff, derby-4451c.stat, derby-4451d.diff, derby-4451d.stat
>
>
> I see this error when I specify the columns in a different order than in the table definition. It only fails if a multi-row table constructor is used.
> ij> create table t(a int, b generated always as (-a));
> 0 rows inserted/updated/deleted
> ij> insert into t(b,a) values (default,1);
> 1 row inserted/updated/deleted
> ij> insert into t(b,a) values (default,1), (default, 2);
> ERROR XJ001: Java exception: '1 >= 1: java.lang.ArrayIndexOutOfBoundsException'.
> And in a sane build:
> ij> insert into t(b,a) values (default,1),(default,2);
> ERROR XJ001: Java exception: 'ASSERT FAILED More columns in result column list than in base table: org.apache.derby.shared.common.sanity.AssertFailure'.
> This bug may be similar to DERBY-4448, but the stack trace is different, and DERBY-4448 does not raise an ASSERT FAILED in sane builds.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4451) ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order

2009-11-24T10:12:39Z

> ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4451
> URL: https://issues.apache.org/jira/browse/DERBY-4451
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Attachments: derby-4451.diff, derby-4451.stat, derby-4451b.diff, derby-4451b.stat, derby-4451c.diff, derby-4451c.stat
>
>
> I see this error when I specify the columns in a different order than in the table definition. It only fails if a multi-row table constructor is used.
> ij> create table t(a int, b generated always as (-a));
> 0 rows inserted/updated/deleted
> ij> insert into t(b,a) values (default,1);
> 1 row inserted/updated/deleted
> ij> insert into t(b,a) values (default,1), (default, 2);
> ERROR XJ001: Java exception: '1 >= 1: java.lang.ArrayIndexOutOfBoundsException'.
> And in a sane build:
> ij> insert into t(b,a) values (default,1),(default,2);
> ERROR XJ001: Java exception: 'ASSERT FAILED More columns in result column list than in base table: org.apache.derby.shared.common.sanity.AssertFailure'.
> This bug may be similar to DERBY-4448, but the stack trace is different, and DERBY-4448 does not raise an ASSERT FAILED in sane builds.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4451) ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order

2009-11-24T10:12:39Z

> ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4451
> URL: https://issues.apache.org/jira/browse/DERBY-4451
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Attachments: derby-4451.diff, derby-4451.stat, derby-4451b.diff, derby-4451b.stat, derby-4451c.diff, derby-4451c.stat
>
>
> I see this error when I specify the columns in a different order than in the table definition. It only fails if a multi-row table constructor is used.
> ij> create table t(a int, b generated always as (-a));
> 0 rows inserted/updated/deleted
> ij> insert into t(b,a) values (default,1);
> 1 row inserted/updated/deleted
> ij> insert into t(b,a) values (default,1), (default, 2);
> ERROR XJ001: Java exception: '1 >= 1: java.lang.ArrayIndexOutOfBoundsException'.
> And in a sane build:
> ij> insert into t(b,a) values (default,1),(default,2);
> ERROR XJ001: Java exception: 'ASSERT FAILED More columns in result column list than in base table: org.apache.derby.shared.common.sanity.AssertFailure'.
> This bug may be similar to DERBY-4448, but the stack trace is different, and DERBY-4448 does not raise an ASSERT FAILED in sane builds.

--
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 883410 - Sun DBTG

2009-11-24T08:55:49Z

[Auto-generated mail]

*Daily* 883410/2009-11-23 18:02:16 MET

Failed Tests OK Skip Duration Suite
-------------------------------------------------------
*Jvm: 1.6*
lin
0 11757 11757 0 1047.67% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 56.78% derbyall
0 2 2 0 572.01% compatibility
0 2 2 0 .% demoSuite
sles
0 11757 11757 0 653.02% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 48.07% derbyall
0 2 2 0 256.50% compatibility
0 2 2 0 .% demoSuite
sol
0 11757 11757 0 820.97% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 42.55% derbyall
0 2 2 0 292.29% compatibility
0 2 2 0 .% demoSuite
solN+1
0 11757 11757 0 140.54% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 66.62% derbyall
0 2 2 0 301.47% compatibility
0 2 2 0 .% demoSuite
sparc
0 11757 11757 0 528.21% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 47.50% derbyall
0 2 2 0 265.92% compatibility
0 2 2 0 .% demoSuite
vista
F:41,E:8 11751 11702 0 129.36% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 58.76% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
vista-64
0 11751 11751 0 187.72% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 57.66% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
w2003
0 11751 11751 0 232.79% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 70.15% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-883410.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/883410_bySig.html

*Jvm: 1.5*
lin
0 222 222 0 51.91% derbyall
F:0,E:1 9967 9966 0 1725.85% suitesAll
sles
0 222 222 0 47.57% derbyall
0 9967 9967 0 1091.72% suitesAll
sol
0 222 222 0 44.86% derbyall
0 9967 9967 0 1521.68% suitesAll
solN+1
0 222 222 0 60.30% derbyall
0 9967 9967 0 1418.41% suitesAll
sparc
0 222 222 0 47.34% derbyall
0 9967 9967 0 1211.11% suitesAll
vista
0 222 222 0 44.80% derbyall
0 9961 9961 0 907.50% suitesAll
vista-64
0 222 222 0 57.96% derbyall
0 9961 9961 0 212.82% suitesAll
w2003
0 222 222 0 54.75% derbyall
0 9961 9961 0 571.34% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-883410.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/FailReports/883410_bySig.html

*Jvm: 1.4*
lin
0 219 219 2 51.74% derbyall
0 9814 9814 0 1549.18% suitesAll
sles
0 219 219 2 45.22% derbyall
0 9814 9814 0 917.18% suitesAll
sol
0 219 219 2 42.38% derbyall
0 9814 9814 0 1234.36% suitesAll
solN+1
0 219 219 2 58.89% derbyall
0 9814 9814 0 1318.20% suitesAll
sparc
0 219 219 2 46.73% derbyall
0 9814 9814 0 1222.10% suitesAll
vista
0 219 219 2 44.28% derbyall
0 9808 9808 0 891.90% suitesAll
vista-64
0 219 219 2 56.82% derbyall
0 9808 9808 0 215.11% suitesAll
w2003
0 219 219 2 56.85% derbyall
0 9814 9814 0 569.38% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-883410.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/FailReports/883410_bySig.html

.......................................................
*Jvm: 1.7*
lin
0 11757 11757 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
0 2 2 0 .% compatibility
0 2 2 0 .% demoSuite
sol
0 11757 11757 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
0 2 2 0 .% compatibility
0 2 2 0 .% demoSuite
vista-64
0 11751 11751 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-883410.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/883410_bySig.html

*Jvm: phoneME*
ubuntu
0 4455 4455 0 .% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/javaME/testing/Limited/testSummary-883410.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/javaME/FailReports/883410_bySig.html

-------------------------------------------------------

Changes in http://dbtg.foundry.sun.com/derby/test/Daily/UpdateInfo/883410.txt

( All results in http://dbtg.foundry.sun.com/derby/test/ )

[jira] Updated: (DERBY-4451) ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order

2009-11-24T08:07:39Z

[ https://issues.apache.org/jira/browse/DERBY-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-4451:
---------------------------------

Attachment: derby-4451d.stat
derby-4451d.diff

Discussed this offline with Knut, it turns out that the removal of generated columns for the case where we have an explicit target column list is not really required. This frees us from having to duplicate the checking if nested DEFAULTs at this stage also, so we can devise a solution which works for all column types; postponed this to DERBY-4426.
The resulting patch is way simpler now:
- drop the call to forbidGenerationOverrides from InsertNode.
- move forbidGenerationOverrides to UpdateNode since it's now only used by that class.
- simplified forbidGenerationOverrides to only handle the update case
- removed the test cases for DERBY-4426 from GeneratedColumnsTest seen in earlier patch versions.
- removed forbidGenerationOverrides from the result sets seen in earlier patch versions.

Rerunning regressions.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-651) Re-enable the storing of java objects in the database

2009-11-24T07:55:39Z

[ https://issues.apache.org/jira/browse/DERBY-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas updated DERBY-651:
--------------------------------

Attachment: derby-651-02-af-udtColumnsRetvalsParams.diff

Attaching derby-651-02-af-udtColumnsRetvalsParams.diff. This patch makes it possible to create UDT columns and store UDTs in them. This patch also makes it possible to pass UDTs as parameters into functions and procedures and to return UDTs from functions. The following is possible with this patch:

create type Price external name 'org.apache.derbyTesting.functionTests.tests.lang.Price' language java;

create table orders( orderID int generated always as identity, customerID int, totalPrice price );

create function makePrice( currencyCode char( 3 ), amount decimal( 31, 5 ), timeInstant Timestamp )
returns Price language java parameter style java no sql
external name 'org.apache.derbyTesting.functionTests.tests.lang.Price.makePrice';
create function getCurrencyCode( price Price ) returns char( 3 ) language java parameter style java no sql
external name 'org.apache.derbyTesting.functionTests.tests.lang.Price.getCurrencyCode';
create function getAmount( price Price ) returns decimal( 31, 5 ) language java parameter style java no sql
external name 'org.apache.derbyTesting.functionTests.tests.lang.Price.getAmount';
create function getTimeInstant( price Price ) returns timestamp language java parameter style java no sql
external name 'org.apache.derbyTesting.functionTests.tests.lang.Price.getTimeInstant';

insert into orders( customerID, totalPrice ) values
( 12345, makePrice( 'USD', cast( 9.99 as decimal( 31, 5 ) ), timestamp('2009-10-16 14:24:43') ) );

select getCurrencyCode( totalPrice ), getAmount( totalPrice ), getTimeInstant( totalPrice ) from orders;

select totalPrice from orders;

At least for small UDTs, it turns out that Derby still has the logic needed to store the UDT values in columns. It appears (although I have not tested this yet), that the Store can probably persist UDT values for UDTs which implement SQLData in addition to UDTs which implement Serializable. What was needed was the ability to identify UDTs by schema qualified names. Touches the following files:

M java/engine/org/apache/derby/iapi/types/TypeId.java
M java/engine/org/apache/derby/iapi/types/UserType.java
M java/engine/org/apache/derby/catalog/TypeDescriptor.java
M java/engine/org/apache/derby/catalog/types/DecimalTypeIdImpl.java
M java/engine/org/apache/derby/catalog/types/TypeDescriptorImpl.java
M java/engine/org/apache/derby/catalog/types/BaseTypeIdImpl.java
M java/engine/org/apache/derby/catalog/types/UserDefinedTypeIdImpl.java

This adds a persistable schema qualified name to the existing UserDefinedType object.

M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
M java/engine/org/apache/derby/impl/sql/compile/MethodCallNode.java
M java/engine/org/apache/derby/impl/sql/compile/ColumnDefinitionNode.java
M java/engine/org/apache/derby/impl/sql/compile/CreateAliasNode.java

Changes to allow schema qualified UDT names in CREATE TABLE/FUNCTION/PROCEDURE statements.

M java/engine/org/apache/derby/impl/sql/compile/QueryTreeNode.java

Adds logic to bind a UDT declaration. This means looking up the UDT in the DataDictionary given its schema qualified name and then poking the corresponding Java class name into the UDT type descriptor.

M java/engine/org/apache/derby/impl/sql/compile/StaticMethodCallNode.java

Small changes to support the use of UDT values at execution time.

A java/testing/org/apache/derbyTesting/functionTests/tests/lang/Price.java
M java/testing/org/apache/derbyTesting/functionTests/tests/lang/UDTTest.java

Some basic tests to verify that you can create columns, parameters, and return values of UDT type.

M java/testing/org/apache/derbyTesting/functionTests/tests/lang/ErrorCodeTest.java
M java/testing/org/apache/derbyTesting/functionTests/master/db2Compatibility.out

Changes some tests to account for the fact that the parser now raises a different error when it encounters illegal type declarations.

The regression tests pass for me.

> Re-enable the storing of java objects in the database
> -----------------------------------------------------
>
> Key: DERBY-651
> URL: https://issues.apache.org/jira/browse/DERBY-651
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Attachments: derby-651-01-aa-basicCreateDropType.diff, derby-651-02-af-udtColumnsRetvalsParams.diff, UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html
>
>
> Islay Symonette, in an email thread called "Storing Java Objects in a table" on October 26, 2005 requests the ability to store java objects in the database.
> Old releases of Cloudscape allow users to declare a column's type to be a Serializable class. This feature was removed from Derby because the syntax was non-standard. However, most of the machinery to support objects serialized to columns is still in Derby and is even used in system tables. We need to agree on some standard syntax here and re-expose this useful feature. Some subset of the ANSI adt syntax, cumbersome as it is, would do.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4153) Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist

2009-11-24T07:31:39Z

[ https://issues.apache.org/jira/browse/DERBY-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781981#action_12781981 ]

Kim Haase commented on DERBY-4153:
----------------------------------

Thanks for working on this, Bryan. I think Rick Hillegas knows the most about security policy files, so you may have to wait till after Thanksgiving for complete info on that.

Here are a few comments (non-technical as usual):

radminconfigdb2jdrdatracedirectory.dita (derby.drda.traceDirectory property):

It seems as if, for these properties, any additional information is provided in the introductory section -- the Default section is used only for a terse statement of the default. Also, the new material seems to apply to an explicitly set property rather than to the default value. So it should be moved, probably to that first section. (Or maybe the Syntax section.)

tadminadv804410.dita (Turning on the trace facility):

I'm glad you noticed that 2 and 3 are alternatives, not sequential steps. It's good to have that corrected.

You may have noticed that our DITA processor pays no attention to those <info> tags. It might be a good idea to make both sets into <p> tags to break up the information, because otherwise they just get munged into one paragraph.

This isn't in the part you are adding, but you may have noticed that there seems to be a missing space on the second line of the NetworkServerControl syntax, between the > and the [. It would be great if you could put that in.

Both topics:

We're not very consistent about the proper font for filenames (derbynet.jar) -- particularly in this book it varies from the <codeph> tag to the <i> tag to the <filepath> tag (the last is ignored by our DITA processor for the HTML frames version; it only works in the PDF and HTML book versions). So take your pick ...

Since DIRECTORY and TRACE DIRECTORY in the security policy lines are meant to be replaceables rather than literals, you might want to follow the customary usage here and put them in lowercase and italics, and make the second into one word (tracedirectory seems most consistent with others in this section).

You might want to put a colon at the ends of the permission lines -- from other examples, this seems to be needed.

You might also add an xref to the topic "Customizing the Network Server's security policy", tadminnetservcustom.dita.

> Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4153
> URL: https://issues.apache.org/jira/browse/DERBY-4153
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.6.0.0
> Reporter: Kathey Marsden
> Assignee: Bryan Pendleton
> Priority: Minor
> Attachments: docs.diff, radminconfigdb2jdrdatracedirectory.html, tadminadv804410.html
>
>
> Starting with 10.5, Network server will attempt to create the trace directory (and any parent directories) if they do not exist. This will require that the derbynet.jar permit verification of the existence of the named trace directory and all necessary parent directories. For each directory created, the policy will require
> permission java.io.FilePermission "<directory>", "read,write"
> and the trace directory will require
> permission java.io.FilePermission "<trace directory>${/}/-", "write"

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4451) ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order

2009-11-24T06:59:39Z

[ https://issues.apache.org/jira/browse/DERBY-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781968#action_12781968 ]

Knut Anders Hatlen commented on DERBY-4451:
-------------------------------------------

If I understand correctly, the patch will disallow DEFAULT in EXCEPT/INTERSECT/UNION, but only for the queries that end up calling ResultSetNode.forbidGenerationOverrides(). This means that it will be disallowed if the DEFAULT is specified for a generated column (not for identity columns or regular columns), and an explicit column list is specified. So given a table

CREATE TABLE T(A INT, B GENERATED ALWAYS AS (-A));

the following is disallowed:

INSERT INTO T(B) VALUES (DEFAULT) UNION VALUES (DEFAULT);
INSERT INTO T(A, B) VALUES (DEFAULT, DEFAULT) UNION VALUES (DEFAULT, DEFAULT);

whereas this is still allowed:

INSERT INTO T(A) VALUES (DEFAULT) UNION VALUES (DEFAULT);
INSERT INTO T VALUES (DEFAULT, DEFAULT) UNION VALUES (DEFAULT, DEFAULT);

Is that about right? If so, using this mechanism to disallow DEFAULT seems to miss most cases, so perhaps it's the wrong place to add this check? Since the checking makes the patch somewhat more complex, and it is not actually needed for this issue (is it?), perhaps it's better to leave it out and try do devise a complete fix in DERBY-4426 instead?

> ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4451
> URL: https://issues.apache.org/jira/browse/DERBY-4451
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Attachments: derby-4451.diff, derby-4451.stat, derby-4451b.diff, derby-4451b.stat, derby-4451c.diff, derby-4451c.stat
>
>
> I see this error when I specify the columns in a different order than in the table definition. It only fails if a multi-row table constructor is used.
> ij> create table t(a int, b generated always as (-a));
> 0 rows inserted/updated/deleted
> ij> insert into t(b,a) values (default,1);
> 1 row inserted/updated/deleted
> ij> insert into t(b,a) values (default,1), (default, 2);
> ERROR XJ001: Java exception: '1 >= 1: java.lang.ArrayIndexOutOfBoundsException'.
> And in a sane build:
> ij> insert into t(b,a) values (default,1),(default,2);
> ERROR XJ001: Java exception: 'ASSERT FAILED More columns in result column list than in base table: org.apache.derby.shared.common.sanity.AssertFailure'.
> This bug may be similar to DERBY-4448, but the stack trace is different, and DERBY-4448 does not raise an ASSERT FAILED in sane builds.

--
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_10.4_16 883622 - Sun Database Engineering

2009-11-24T04:02:30Z

[Auto-generated mail]

*tinderbox_10.4_16* 883622/2009-11-24 09:35:43 CET

Failed Tests OK Skip Duration Suite
-------------------------------------------------------
*Jvm: 1.6*
SunOS-5.10_i86pc-i386
0 2 2 0 105.00% org.apache.derbyTesting.functionTests.tests.demo._Suite
0 10628 10628 0 81.48% org.apache.derbyTesting.functionTests.suites.All
1 272 271 0 88.49% derbyall
0 2 2 0 170.21% org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilityCombinations
Details in http://dbtg.foundry.sun.com/derby/test/tinderbox_10.4_16/jvm1.6/testing/Limited/testSummary-883622.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/tinderbox_10.4_16/jvm1.6/FailReports/883622_bySig.html
-------------------------------------------------------

Changes in http://dbtg.foundry.sun.com/derby/test/tinderbox_10.4_16/UpdateInfo/883622.txt

( All results in http://dbtg.foundry.sun.com/derby/test/ )

[jira] Subscription: Derby: JIRA issues with patch available

2009-11-24T00:36:39Z

Issue Subscription
Filter: Derby: JIRA issues with patch available (12 issues)
Subscriber: derby-dev

Key Summary
DERBY-4451 ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order
https://issues.apache.org/jira/browse/DERBY-4451
DERBY-4428 Add proper delete mechanism for in-memory databases
https://issues.apache.org/jira/browse/DERBY-4428
DERBY-651 Re-enable the storing of java objects in the database
https://issues.apache.org/jira/browse/DERBY-651
DERBY-4357 TableFunctions provide no information to limit underlying query
https://issues.apache.org/jira/browse/DERBY-4357
DERBY-4183 Our regression tests use various jar files for which we don't have build scripts.
https://issues.apache.org/jira/browse/DERBY-4183
DERBY-151 Thread termination -> XSDG after operation is 'complete'
https://issues.apache.org/jira/browse/DERBY-151
DERBY-1191 Some SQLExceptions, for example those generated from BrokeredStatements, do not print to derby.log even when derby.stream.error.logSeverityLevel=0
https://issues.apache.org/jira/browse/DERBY-1191
DERBY-4272 SQL Authorization Support for dblook
https://issues.apache.org/jira/browse/DERBY-4272
DERBY-873 OSGi bundle activator not JSR169 compliant
https://issues.apache.org/jira/browse/DERBY-873
DERBY-4137 OOM issue using XA with timeouts
https://issues.apache.org/jira/browse/DERBY-4137
DERBY-3788 Provide a zero-admin way of updating the statisitcs of an index
https://issues.apache.org/jira/browse/DERBY-3788
DERBY-4241 Improve transition from read-only to writable Clob representation
https://issues.apache.org/jira/browse/DERBY-4241

You may edit this subscription at:
https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?subId=10396&filterId=12310751

[jira] Commented: (DERBY-4453) OnlineBackupTest1 nightly test failed with "java.io.EOFException: Reached end of file while attempting to read a whole page."

2009-11-24T00:06:39Z

[ https://issues.apache.org/jira/browse/DERBY-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781814#action_12781814 ]

Ole Solberg commented on DERBY-4453:
------------------------------------

The complete log from the test is now available as
http://dbtg.foundry.sun.com/derby/test/debug/882732.zip

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3225) Some demo programs in -bin distributions are not mentioned in demo/programs/readme.html

2009-11-23T23:58:39Z

[ https://issues.apache.org/jira/browse/DERBY-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John H. Embretsen closed DERBY-3225.
------------------------------------

Thanks Bryan, the final changes look good to me. Closing.

> Some demo programs in -bin distributions are not mentioned in demo/programs/readme.html
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-3225
> URL: https://issues.apache.org/jira/browse/DERBY-3225
> Project: Derby
> Issue Type: Improvement
> Components: Demos/Scripts
> Affects Versions: 10.3.1.4
> Environment: Derby -bin distributions
> Reporter: John H. Embretsen
> Assignee: Bryan Pendleton
> Fix For: 10.6.0.0
>
> Attachments: derby-3225.diff
>
>
> Currently in trunk, there are 8 demo (sub)directories in the demo/programs directory scheduled to be included in -bin distributions, each containing one or more demo or sample applications:
> localcal/
> nserverdemo/
> scores/
> simple/
> simplemobile/
> toursdb/
> vtis/
> workingwithderby/
> With a -bin distribution of Derby, a user should be able to get an overview of the included demo program offering by opening demo/programs/readme.html in a web browser (there is a link to this from the top-level index.html file). In trunk, we are currently missing short descriptions of and links to:
> - localcal (see DERBY-1936) [also in 10.3]
> - scores (see DERBY-1993) [also in 10.3]
> - vtis (see DERBY-3129)
> Each of these demos have a README file in their respective subdirectories, that could easily be linked to.*
> The remaining 5 demos are accessible from and described by the readme.html file (readme.html is a frameset; the actual references and descriptions are in navbar.html and demo.html. These files are placed in the java/demo directory in the source tree).
> *)
> Also, one should make sure that the README files and other instructions are suitable for -bin distributions, not only -src distributions or SVN working copies. Otherwise, these particular demos should not be included in -bin distributions. For example both localcal/README, scores/README and vtis/README currently refer to build scripts that are not scheduled for inclusion in -bin distros.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3947) Cannot insert 994 character long string into indexed column

2009-11-23T20:38:41Z

[ https://issues.apache.org/jira/browse/DERBY-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781770#action_12781770 ]

Bryan Pendleton commented on DERBY-3947:
----------------------------------------

I fiddled with this problem for a little while, and I think that the
problem is that the index which is created behind-the-scenes to
implement the PRIMARY KEY constraint goes through a different
code path than the normal index which is created by CREATE INDEX.

In the case of

create table t (x varchar(1000));
create index t_ix on t(x);

we go through CreateIndexNode.makeConstantAction, where there
is code that looks at the size of the columns in the index and notices
that we need a larger page size for this index, and chooses the
larger page size automatically.

But in the case from the issue description

create table t (x varchar(1000) primary key)

we *instead* go through TableElementNode.genIndexAction,
which doesn't have any logic to notice that a larger page size is needed.

I think that we could fix this problem by arranging for the colInfos data
from the CreateTableNode to be passed through to TableElementNode.genIndexAction
so that it can check the size of the columns and see if it needs to create the
PRIMARY KEY index with a larger page size.

Ideally, it would be great if we could somehow share this code between
CreateIndexNode and TableElementNode, but I think that the data
structures are unfortunately not very similar so we may end up
with two bits of code instead.

At least, I can *start* by writing a second bit of code and demonstrating
that it fixes the problem, and then we can try to figure out how to share
the code and only compute the index's needed page size once.

> Cannot insert 994 character long string into indexed column
> -----------------------------------------------------------
>
> Key: DERBY-3947
> URL: https://issues.apache.org/jira/browse/DERBY-3947
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.4.2.0
> Reporter: Knut Anders Hatlen
> Assignee: Bryan Pendleton
> Attachments: VarcharIndex.java
>
>
> Inserting a 994 character string into a varchar(1000) column with an index fails.
> These steps
> 1. "create table t (x varchar(1000) primary key)"
> 2. "insert into t values (?)" where ? holds a 994 character string
> produce the following error:
> ERROR XSCB6: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation.
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276)
> at org.apache.derby.impl.store.access.btree.BTreeController.doIns(BTreeController.java:845)
> at org.apache.derby.impl.store.access.btree.BTreeController.insert(BTreeController.java:1264)
> at org.apache.derby.impl.store.access.btree.index.B2IController.insert(B2IController.java:210)
> at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(IndexChanger.java:439)
> at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(IndexChanger.java:383)
> at org.apache.derby.impl.sql.execute.IndexChanger.insert(IndexChanger.java:589)
> at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(IndexSetChanger.java:268)
> at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java:453)
> at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1011)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:487)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:372)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
> The page size should be set sufficiently high at index creation time to hold columns with the specified maximum size.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-3947) Cannot insert 994 character long string into indexed column

2009-11-23T20:24:40Z

[ https://issues.apache.org/jira/browse/DERBY-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton reassigned DERBY-3947:
--------------------------------------

Assignee: Bryan Pendleton

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Fwd: [jira] Account signup

2009-11-23T19:57:09Z

Hi,
I am Jayaram Subramanian, having 10 years of experience in IT. Currently i am trying to make a career in the JAVA platform and consider being a mentee under Apache mentoring program for Derby project a great opportunity to develop myself. Please find my JIRA details. Could i please be added under the developer group.

With Regards
Jayaram

---------- Forwarded message ----------

From: <jira@...>
Date: Mon, Nov 23, 2009 at 10:48 PM
Subject: [jira] Account signup
To: rsjay1976@...

You have signed up for a JIRA account at:

https://issues.apache.org/jira

Here are the details of your account:
---------------------------------------------------------------------
Username: rsjay1976
Email: rsjay1976@...
Full Name: Jayaram Subramanian
Password: gjay1976
(You can always retrieve these via the "Forgot Password" link on the signup page)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3225) Some demo programs in -bin distributions are not mentioned in demo/programs/readme.html

2009-11-23T17:56:39Z

[ https://issues.apache.org/jira/browse/DERBY-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton resolved DERBY-3225.
------------------------------------

Resolution: Fixed
Fix Version/s: 10.6.0.0

Thanks John! The instructions for building a private release worked well; I was
able to build and test the changes to release/build.xml.

I fixed the typos that you noticed, and committed the changes to the
trunk as revision 883571.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4451) ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order

2009-11-23T17:50:39Z

[ https://issues.apache.org/jira/browse/DERBY-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-4451:
---------------------------------

Attachment: derby-4451c.stat
derby-4451c.diff

Uploading derby-4451c, which fixes the case seen by Knut. It also now handles INTERSECT/EXCEPT and any nested use of DEFAULT, i.e. use of DEFAULT is only allowed in a top level table constructor. Note that this does not solve DERBY-4426, which does not have an explicit target column list, and so is not checked by forbidGenerationOverrides#forbidGenerationOverrides. We do need to add this logic here, though, for otherwise we would lose the information that the user provided a default in a nested table constructor (it would be pruned away). The alternative would be to just throw LANG_CANT_OVERRIDE_GENERATION_CLAUSE, but that could be confusing for the following query:

insert into t(a,b) values (3,default) union all values (3,default)

Added more test cases, rerunning regressions.

> ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4451
> URL: https://issues.apache.org/jira/browse/DERBY-4451
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Attachments: derby-4451.diff, derby-4451.stat, derby-4451b.diff, derby-4451b.stat, derby-4451c.diff, derby-4451c.stat
>
>
> I see this error when I specify the columns in a different order than in the table definition. It only fails if a multi-row table constructor is used.
> ij> create table t(a int, b generated always as (-a));
> 0 rows inserted/updated/deleted
> ij> insert into t(b,a) values (default,1);
> 1 row inserted/updated/deleted
> ij> insert into t(b,a) values (default,1), (default, 2);
> ERROR XJ001: Java exception: '1 >= 1: java.lang.ArrayIndexOutOfBoundsException'.
> And in a sane build:
> ij> insert into t(b,a) values (default,1),(default,2);
> ERROR XJ001: Java exception: 'ASSERT FAILED More columns in result column list than in base table: org.apache.derby.shared.common.sanity.AssertFailure'.
> This bug may be similar to DERBY-4448, but the stack trace is different, and DERBY-4448 does not raise an ASSERT FAILED in sane builds.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (DERBY-858) ijConnName test output order is non-deterministic.

2009-11-23T14:58:39Z

[ https://issues.apache.org/jira/browse/DERBY-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren reopened DERBY-858:
--------------------------------------

Reopening to address an issue with the SysinfoTest on DOS (i.e. Windows but not using a shell environment like cygwin); it will give a diff like so:
1) testSysinfoLocale(org.apache.derbyTesting.functionTests.tests.derbynet.SysinfoTest)junit.framework.AssertionFailedError: expected:<14> but was:<1>
at org.apache.derbyTesting.functionTests.tests.derbynet.SysinfoTest.assertMatchingStringExists(SysinfoTest.java:322)
at org.apache.derbyTesting.functionTests.tests.derbynet.SysinfoTest.testSysinfoLocale(SysinfoTest.java:249)

> ijConnName test output order is non-deterministic.
> --------------------------------------------------
>
> Key: DERBY-858
> URL: https://issues.apache.org/jira/browse/DERBY-858
> Project: Derby
> Issue Type: Bug
> Components: Test
> Reporter: Daniel John Debrunner
> Assignee: Myrna van Lunteren
> Priority: Minor
> Fix For: 10.5.3.1, 10.6.0.0
>
> Attachments: DERBY-858.diff, DERBY-858.diff2, DERBY-858_105.diff
>
>
> The test loads four initial connections using these ij.connection properties in the test's _app.properties file.
> ij.connection.connOne=jdbc:derby:wombat;create=true
> ij.connection.connTwo=jdbc:derby:lemming;create=true
> ij.connection.connThree=jdbc:noone:fruitfly;create=true
> ij.connection.connFour=jdbc:derby:nevercreated
> The order these connections are created, and hence the order of the test output is only determined by the hash table ordering of the properties file. Making small changes in ijConnName_app.properties files can change the order, making the test appear to fail.
> E.g. I tried to enable the test with a security manager by modifying the noSecurityManger to be set to false, and the order changed.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-4451) ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order

2009-11-23T13:55:40Z

[ https://issues.apache.org/jira/browse/DERBY-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781493#action_12781493 ]

Dag H. Wanvik edited comment on DERBY-4451 at 11/23/09 9:54 PM:
----------------------------------------------------------------

Thanks for looking at the patch, guys. Interestingly,

insert into t(x,y) select * from t union select * from t;

gives the ArrayIndexOutOfBoundsException, but this version:

ij(CONNECTION1)> insert into t(y,x) select * from t union select * from t;
ERROR 42XA3: You may not override the value of generated column 'Y'.

works as expected. I also see that the patch doesn't handle INTERSECT/EXCEPT properly, but that's easily fixed by moving the mothod from UnionNode up to SetOperatorNode. I'll spin a new verision when I have figured out the ArrayIndexOutOfBoundsException case. Another thing is that the new version would silently remove the defaults in this case (DERBY-4426 variant):

create table mytab (i int generated always as (j*2), j int);
insert into mytab(i,j) values (default,1) union values (default,2);

wheres they should be flagged according to the discussion in DERBY-4426..

was (Author: dagw):
Thanks for looking at the patch, guys. Interestingly,

insert into t(x,y) select * from t union select * from t;

gives the ArrayIndexOutOfBoundsException, but this version:

ij(CONNECTION1)> insert into t(y,x) select * from t union select * from t;
ERROR 42XA3: You may not override the value of generated column 'Y'.

works as expected. I also see that the patch doesn't handle INTERSECT/EXCEPT properly, but that's easily fixed by moving the mothod from UnionNode up to SetOperatorNode. I'll spin a new verision when I have figured out the ArrayIndexOutOfBoundsException case. Another thing is that thew new version would silently remove the defaults in this case (DERBY-4426):

create table mytab (i int generated always as (j*2), j int);
insert into mytab values (default,1) union values (default,2);

wheres they should be flagged according to the discussion in DERBY-4426..

> ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated columns out of order
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4451
> URL: https://issues.apache.org/jira/browse/DERBY-4451
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Attachments: derby-4451.diff, derby-4451.stat, derby-4451b.diff, derby-4451b.stat
>
>
> I see this error when I specify the columns in a different order than in the table definition. It only fails if a multi-row table constructor is used.
> ij> create table t(a int, b generated always as (-a));
> 0 rows inserted/updated/deleted
> ij> insert into t(b,a) values (default,1);
> 1 row inserted/updated/deleted
> ij> insert into t(b,a) values (default,1), (default, 2);
> ERROR XJ001: Java exception: '1 >= 1: java.lang.ArrayIndexOutOfBoundsException'.
> And in a sane build:
> ij> insert into t(b,a) values (default,1),(default,2);
> ERROR XJ001: Java exception: 'ASSERT FAILED More columns in result column list than in base table: org.apache.derby.shared.common.sanity.AssertFailure'.
> This bug may be similar to DERBY-4448, but the stack trace is different, and DERBY-4448 does not raise an ASSERT FAILED in sane builds.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4453) OnlineBackupTest1 nightly test failed with "java.io.EOFException: Reached end of file while attempting to read a whole page."

2009-11-23T10:57:40Z

[ https://issues.apache.org/jira/browse/DERBY-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781540#action_12781540 ]

Myrna van Lunteren commented on DERBY-4453:
-------------------------------------------

I looked at archived old test results and this failure has not shown up in the nightly tests at IBM for about 2 1/2 years (oldest results were 2007-06-13).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4453) OnlineBackupTest1 nightly test failed with "java.io.EOFException: Reached end of file while attempting to read a whole page."

2009-11-23T10:45:39Z

[ https://issues.apache.org/jira/browse/DERBY-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781534#action_12781534 ]

Myrna van Lunteren commented on DERBY-4453:
-------------------------------------------

I wonder if this is the same issue as DERBY-973?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4453) OnlineBackupTest1 nightly test failed with "java.io.EOFException: Reached end of file while attempting to read a whole page."

2009-11-23T10:43:40Z

[ https://issues.apache.org/jira/browse/DERBY-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-4453:
----------------------------------

I can't really tell anything from the info available publicly. Is it possible for someone to zip up whatever is left of running of this test. At least derby.log, but the whole directory with the database and the backup would help.

I did a quick search and I did not come up with this failing for quite awhile. If anyone knows of a recently nightly error in this test go ahead an add it to this bug. Or if anyone
has seen this recently on the trunk also post it.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DERBY-4453) OnlineBackupTest1 nightly test failed with "java.io.EOFException: Reached end of file while attempting to read a whole page."

2009-11-23T10:25:40Z

OnlineBackupTest1 nightly test failed with "java.io.EOFException: Reached end of file while attempting to read a whole page."
-----------------------------------------------------------------------------------------------------------------------------

Key: DERBY-4453
URL: https://issues.apache.org/jira/browse/DERBY-4453
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.6.0.0
Environment: ------------------ Java Information ------------------
Java Version: 1.6.0_15
Java Vendor: Sun Microsystems Inc.
Java home: /usr/local/java/jdk1.6.0_15/jre
Java classpath: /home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derby.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyclient.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbytools.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbynet.jar:/home/os136789/Apache/TinderBox_Derby/db2jcc/lib/db2jcc.jar:/home/os136789/Apache/TinderBox_Derby/db2jcc/lib/db2jcc_license_c.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyTesting.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyrun.jar:/home/os136789/Apache/TinderBox_Derby/trunk/tools/java/jakarta-oro-2.0.8.jar:/home/os136789/Apache/TinderBox_Derby/trunk/tools/java/junit.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_de_DE.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_es.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_fr.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_it.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_ja_JP.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_ko_KR.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_pt_BR.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_zh_CN.jar:/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyLocale_zh_TW.jar:/usr/local/share/java/xalan/serializer.jar:/usr/local/share/java/xalan/xalan.jar:/usr/local/share/java/xalan/xercesImpl.jar:/usr/local/share/java/xalan/xml-apis.jar:/usr/local/share/java/xalan/xsltc.jar
OS name: SunOS
OS architecture: x86
OS version: 5.10
Java user name: os136789
Java user home: /home/os136789
Java user dir: /export/home/tmp/os136789/testingDerbyTinderBox/SunOS-5.10_i86pc-i386/derbyall
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
--------- Derby Information --------
JRE - JDBC: Java SE 6 - JDBC 4.0
[/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derby.jar] 10.6.0.0 alpha - (882732)
[/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbytools.jar] 10.6.0.0 alpha - (882732)
[/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbynet.jar] 10.6.0.0 alpha - (882732)
[/home/os136789/Apache/TinderBox_Derby/trunk/jars/insane/derbyclient.jar] 10.6.0.0 alpha - (882732)
[/home/os136789/Apache/TinderBox_Derby/db2jcc/lib/db2jcc.jar] 2.4 - (17)
[/home/os136789/Apache/TinderBox_Derby/db2jcc/lib/db2jcc_license_c.jar] 2.4 - (17)

Reporter: Mike Matrigali

Online backup test failed in nightly tinderbox run:

http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/882732-derbyall_diff.txt

Failure Details:
********* Diff file derbyall/derbynetmats/DerbyNet/jdbcapi/derbyStress.diff
*** Start: derbyStress jdk1.6.0_15 DerbyNet derbynetmats:jdbcapi 2009-11-21 00:07:40 ***
Test skipped: listed in DerbyNet.exclude file, skipping test: jdbcapi/derbyStress.java
*** End: derbyStress jdk1.6.0_15 DerbyNet derbynetmats:jdbcapi 2009-11-21 00:07:40 ***
********* Diff file derbyall/storeall/storemore/OnlineBackupTest1.diff
*** Start: OnlineBackupTest1 jdk1.6.0_15 storeall:storemore 2009-11-21 00:13:18 ***
6 del
< Restored From the Backup
7 del
< Consistency Check is Done
8 del
< database shutdown properly
9 del
< End Online Backup Test1
9 add

> ERROR XJ040: Failed to start database 'wombat', see the next exception for details.
> ERROR XSDG0: Page Page(3,Container(0, 40768)) could not be read from disk.
> java.sql.SQLException: Failed to start database 'wombat', see the next exception for details.
> Caused by: java.sql.SQLException: Failed to start database 'wombat', see the next exception for details.
> ... 16 more
> Caused by: java.sql.SQLException: Page Page(3,Container(0, 40768)) could not be read from disk.
> ... 13 more
> Caused by: ERROR XSDG0: Page Page(3,Container(0, 40768)) could not be read from disk.
> ... 13 more
> Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page.
> ... 42 more

Test Failed.
*** End: OnlineBackupTest1 jdk1.6.0_15 storeall:storemore 2009-11-21 00:14:25 ***
********* Diff file derbyall/derbynetclientmats/DerbyNetClient/encodingTests/TestEnc.diff
*** Start: TestEnc jdk1.6.0_15 DerbyNetClient derbynetclientmats:encodingTests 2009-11-21 00:20:39 ***
derbyTesting.encoding can only be used with jdk15, skipping test
*** End: TestEnc jdk1.6.0_15 DerbyNetClient derbynetclientmats:encodingTests 2009-11-21 00:20:39 ***
------------------------------------------------------

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4153) Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist

2009-11-23T09:55:39Z

[ https://issues.apache.org/jira/browse/DERBY-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton updated DERBY-4153:
-----------------------------------

Attachment: tadminadv804410.html
radminconfigdb2jdrdatracedirectory.html
docs.diff

Now that the various code bugs have been fixed, it seems safe
to proceed with this documentation improvement. I think that
there are two places in the admin guide where this documentation
would be useful: in the derby.drda.traceDirectory page, and in the
page about how to turn tracing on.

I tried to use the security policy lines verbatim from the JIRA description,
but because I find Java security policy a bit confusing, I'm hoping that
somebody who's more comfortable reading security policy syntax can
check to see that they look accurate.

Attached is a proposed diff for the docs, and the two revised HTML pages.

Please let me know how they look.

> Document that starting with 10.5 network server will attempt to create the trace directory if it does not exist
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4153
> URL: https://issues.apache.org/jira/browse/DERBY-4153
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.6.0.0
> Reporter: Kathey Marsden
> Assignee: Bryan Pendleton
> Priority: Minor
> Attachments: docs.diff, radminconfigdb2jdrdatracedirectory.html, tadminadv804410.html
>
>
> Starting with 10.5, Network server will attempt to create the trace directory (and any parent directories) if they do not exist. This will require that the derbynet.jar permit verification of the existence of the named trace directory and all necessary parent directories. For each directory created, the policy will require
> permission java.io.FilePermission "<directory>", "read,write"
> and the trace directory will require
> permission java.io.FilePermission "<trace directory>${/}/-", "write"

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.