[jira] Updated: (DERBY-3382) Replication: Slave must inform master if DBs are out of sync.
[ https://issues.apache.org/jira/browse/DERBY-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3382: - Attachment: derby-3382-test-1b.diff derby-3382-test-1b.stat Thank you for the review, Øystein. Patch 1b addresses your comments. After updating my sandbox, I got the same exception as you did. It turned out to be caused by another patch invalidating mine. The replication test suite completed successfully. Requesting review. Replication: Slave must inform master if DBs are out of sync. - Key: DERBY-3382 URL: https://issues.apache.org/jira/browse/DERBY-3382 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0 Reporter: Øystein Grøvlen Assignee: Jørgen Løland Fix For: 10.4.0.0 Attachments: derby-3382-1a.diff, derby-3382-1a.stat, derby-3382-1b.diff, derby-3382-1b.stat, derby-3382-test-1a.diff, derby-3382-test-1a.stat, derby-3382-test-1b.diff, derby-3382-test-1b.stat If I copy the database to the slave before booting the master, slave will be out of sync with the master since new log records are created during booting. The slave will then stop replication, but the master will not be notified. If I then try to stop or failover the master the master will hang. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3551: -- Assignee: V.Narayanan Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() -- Key: DERBY-3551 URL: https://issues.apache.org/jira/browse/DERBY-3551 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Jorgen says- I suggest that the replication step in which the master database is frozen is replaced by a new system procedure to solve index and import: Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() The new system procedure should: 1) Freeze the database 2) Check if there are any ongoing transactions with unlogged operations. If so - unfreeze and abort. Otherwise: 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580259#action_12580259 ] V.Narayanan commented on DERBY-3551: I have been trying to understand how I can enable logging for unlogged operations. My guide so far has been JIRA comments and code related to DERBY-239 - Need a online backup feature that does not block update operations when online backup is in progress. Derby-239 enables logging for unlogged operations by turning on the logArchived mode. Turning on logArchived mode from my understanding, archives logs as well as logs unlogged operations. But for replication archiving of logs is not necessary, we need to only turn on the logging. I am investigating further on how this alone can be done. Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() -- Key: DERBY-3551 URL: https://issues.apache.org/jira/browse/DERBY-3551 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Jorgen says- I suggest that the replication step in which the master database is frozen is replaced by a new system procedure to solve index and import: Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() The new system procedure should: 1) Freeze the database 2) Check if there are any ongoing transactions with unlogged operations. If so - unfreeze and abort. Otherwise: 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580265#action_12580265 ] Jørgen Løland commented on DERBY-3169: -- I've seen some JIRA comments on other issues that propose additional things that may need to be documented -- like a SYSCS_UTIL.SYSCS_PREPARE_REPLICATION procedure, for example. Please let me know when/if further changes are necessary. Of course (and I'm amazed that that discussion didn't go below your radar :) ) The appropriate action for DERBY-3533 has not been decided upon yet, but if the current suggestion is used, the doc-changes will be minimal. Add documentation for replication - Key: DERBY-3169 URL: https://issues.apache.org/jira/browse/DERBY-3169 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Kim Haase Attachments: DERBY-3169-2.diff, DERBY-3169-2.stat, DERBY-3169-2.zip, DERBY-3169-3.diff, DERBY-3169-3.stat, DERBY-3169-3.zip, DERBY-3169-4.diff, DERBY-3169-4.zip, DERBY-3169.diff, DERBY-3169.stat, DERBY-3169.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3499) testStartStopManagementFromApplication junit test failure in nightly test suite.
[ https://issues.apache.org/jira/browse/DERBY-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580275#action_12580275 ] Jørgen Løland commented on DERBY-3499: -- A similar bug has been around in all tinderbox tests between 636894 and 638427 (current): 1) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:2 but was:5 at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86) at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) testStartStopManagementFromApplication junit test failure in nightly test suite. Key: DERBY-3499 URL: https://issues.apache.org/jira/browse/DERBY-3499 Project: Derby Issue Type: Bug Components: JMX Affects Versions: 10.4.0.0 Reporter: Mike Matrigali Assignee: Daniel John Debrunner Fix For: 10.4.0.0 The following is failing in the nightly tinderbox tests. For example of first failure see: http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/633700-org.apache.derbyTesting.functionTests.suites.All_diff.txt 1) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:2 but was:1 at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86) at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580295#action_12580295 ] Jørgen Løland commented on DERBY-3169: -- Patch 4 looks very good. I have only one minor comment: adminguide/cadminreplicfailover.html Change slave to master on this line: You perform failover from the master system. To do so, you connect to the database on the slave system using the failover=true connection URL attribute. Thank you very much for all the great work, Kim! Add documentation for replication - Key: DERBY-3169 URL: https://issues.apache.org/jira/browse/DERBY-3169 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Kim Haase Attachments: DERBY-3169-2.diff, DERBY-3169-2.stat, DERBY-3169-2.zip, DERBY-3169-3.diff, DERBY-3169-3.stat, DERBY-3169-3.zip, DERBY-3169-4.diff, DERBY-3169-4.zip, DERBY-3169.diff, DERBY-3169.stat, DERBY-3169.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[
https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
V.Narayanan updated DERBY-3551:
---
Attachment: Derby3551_1.stat
Derby3551_1.diff
In trying to search for a way to enable only logging of unlogged operations and
not the archiving support available the following observations were very
important
1) Logic to enable logging is found in the BaseDataFileFactory
(org.apache.derby.impl.store.raw.data.BaseDataFileFactory, line no 672)
2) Logic for archiving is present in LogToFile
This partitioning of logic was to the advantage of this issue and made the
coding
logic very simple
Follows a brief explanation of the solution developed
When log archiving needs to be done it is enabled by using a flag in the
following way in the BaseDataFileFactory
if (logFactory.logArchived()) {
mode = ~(ContainerHandle.MODE_UNLOGGED |
ContainerHandle.MODE_CREATE_UNLOGGED);
}
(The ContainerHandle class contains a very good explanation of the
MODE_UNLOGGED,
MODE_CREATE_UNLOGGED flags.)
Now in addition to just enabling the flags when logArchiving is required the
flags need
to be enabled when replication is active too. To achieve this the above code
was changed to
if (logFactory.logArchived() || logFactory.replicationLogUnlogged()) {
mode = ~(ContainerHandle.MODE_UNLOGGED |
ContainerHandle.MODE_CREATE_UNLOGGED);
}
Doing the above solved the problem for a simple index creation, what remains to
be seen
is how it works for imports.
Attaching a patch for people who might be interested in testing the solution.
Another interesting decision will be as to whether a stored procedure will be
required now?
(I do not have an answer for this right now, but I surely shall be revisiting
Derby-239 to learn
more about unlogged operations being started before logging is enabled)
Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
--
Key: DERBY-3551
URL: https://issues.apache.org/jira/browse/DERBY-3551
Project: Derby
Issue Type: Sub-task
Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
Attachments: Derby3551_1.diff, Derby3551_1.stat
Jorgen says-
I suggest that the replication step in which the master database is frozen is
replaced by a new system procedure to solve index and import:
Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE()
New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
The new system procedure should:
1) Freeze the database
2) Check if there are any ongoing transactions with unlogged operations. If
so - unfreeze and abort. Otherwise:
3) Enable logging of unlogged operations
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580338#action_12580338 ] V.Narayanan commented on DERBY-3551: Please note that Derby3551_1 is not for a commit. It is just for testing the solution. There are many other questions remaining unanswered. 1) Is a stored procedure for starting replication required? 2) What are the behaviour of imports? (There is a separate issue for jars) 3) Tests need to be written for unlogged operations in the context of replication (there is a separate JIRA for this too) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() -- Key: DERBY-3551 URL: https://issues.apache.org/jira/browse/DERBY-3551 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: Derby3551_1.diff, Derby3551_1.stat Jorgen says- I suggest that the replication step in which the master database is frozen is replaced by a new system procedure to solve index and import: Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() The new system procedure should: 1) Freeze the database 2) Check if there are any ongoing transactions with unlogged operations. If so - unfreeze and abort. Otherwise: 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Eclipse plugin
Manjula Kutty [EMAIL PROTECTED] writes: Hi, I have seen that some changes had gone in to the eclipse plugin since 10.3.1.4 release. But the version is still 1.1.1. I strongly feel that we should make the version to 1.1.2. what do you think? Sounds reasonable enough to me, but I'm not an eclipse expert (or even a user), so I'll let others weigh in. Also if I make the changes to the plugin.xml do I have check that in and build the core plugin again? Don't know about plugin.xml, but for the rest of Derby it seems like you have to do ant clobber and build again to make version number changes take effect... -- dt
[jira] Commented: (DERBY-3545) NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation
[ https://issues.apache.org/jira/browse/DERBY-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580349#action_12580349 ] Rick Hillegas commented on DERBY-3545: -- What was the shell command you issued which generated this output? NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation - Key: DERBY-3545 URL: https://issues.apache.org/jira/browse/DERBY-3545 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.1.0, 10.5.0.0 Environment: IBM 1.5 - linux - insane jars Reporter: Daniel John Debrunner Attachments: TEST-org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.xml Running the tests through ant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-39) Strange error in JOIN ON clause
[ https://issues.apache.org/jira/browse/DERBY-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-39: Component/s: (was: Newcomer) I don't think this is a newcomer issue. Unmarking it as such. Strange error in JOIN ON clause --- Key: DERBY-39 URL: https://issues.apache.org/jira/browse/DERBY-39 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Erik Bengtson Attachments: d39.sql, derby-joinon.tar.gz The exception: --- Error: An ON clause associated with a JOIN operator is not valid. --- happens when I run the below SQL script: --- SELECT THIS.DOSSIERTEMPLATE_ID FROM DOSSIERTEMPLATE THIS, ENTITLEMENT UNBOUND_ENTITLE INNER JOIN ENTITLEMENT II ON UNBOUND_ENTITLE.ENTITLEMENT_ID = II.ENTITLEMENT_ID INNER JOIN DOSSIERTEMPLATERESOURCE BB ON II.ENTITLED_TO_RESOURCE_ID_OID = BB.DOSSIERTEMPLATERESOURCE_ID INNER JOIN I18N THIS_LABEL ON THIS.LABEL_I18N_ID_OID = THIS_LABEL.I18N_ID --- It works fine if I run without the LABEL join --- SELECT THIS.DOSSIERTEMPLATE_ID FROM DOSSIERTEMPLATE THIS, ENTITLEMENT UNBOUND_ENTITLE INNER JOIN ENTITLEMENT II ON UNBOUND_ENTITLE.ENTITLEMENT_ID = II.ENTITLEMENT_ID INNER JOIN DOSSIERTEMPLATERESOURCE BB ON II.ENTITLED_TO_RESOURCE_ID_OID = BB.DOSSIERTEMPLATERESOURCE_ID --- The column LABEL_I18N_ID_OID is BIGINT and has a FK to I18N_ID, which is BIGINT as well -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Summer of Code 2008 - A few Questions
Christopher Saunders wrote: I am interested in getting involved with the summer of code but would like to ask a few questions. I am going to be going to classes this summer semester but would still like to contribute to the derby project. I think typically students are working full time on Google Soc, but I guess it is really up to you and how much you can handle. It is hard for me to say without knowing your work. Are you a graduate student or undergrad? Perhaps some of our past students can comment on whether they think it is feasible to take classes at the same time. If you don't want the pressure of a formal project and setting goals etc, you can still contribute and just not participate in the program. To get a feel for how you'll do, set up your build and test environment and see how long it takes to get the tests running cleanly, then maybe get started on converting a JUnit test or pickup a Newcomer issue. If you can achieve these goals by March 31, (the application deadline), I think you should be fine. See: http://wiki.apache.org/db-derby/DerbyDev for tips on getting started. Kathey
Re: Summer of Code 2008 - A few Questions
Thanks a lot for the response. I'll give all of that a try and see how far I can get. Kathey Marsden wrote: Christopher Saunders wrote: I am interested in getting involved with the summer of code but would like to ask a few questions. I am going to be going to classes this summer semester but would still like to contribute to the derby project. I think typically students are working full time on Google Soc, but I guess it is really up to you and how much you can handle. It is hard for me to say without knowing your work. Are you a graduate student or undergrad? Perhaps some of our past students can comment on whether they think it is feasible to take classes at the same time. If you don't want the pressure of a formal project and setting goals etc, you can still contribute and just not participate in the program. To get a feel for how you'll do, set up your build and test environment and see how long it takes to get the tests running cleanly, then maybe get started on converting a JUnit test or pickup a Newcomer issue. If you can achieve these goals by March 31, (the application deadline), I think you should be fine. See: http://wiki.apache.org/db-derby/DerbyDev for tips on getting started. Kathey
Re: Eclipse plugin
On 3/18/08, Manjula Kutty [EMAIL PROTECTED] wrote: Hi, I have seen that some changes had gone in to the eclipse plugin since 10.3.1.4 release. But the version is still 1.1.1. I strongly feel that we should make the version to 1.1.2. what do you think? Also if I make the changes to the plugin.xml do I have check that in and build the core plugin again? -Manjula You're right Manjula, I also think we should get a new version number before releasing the updated plugin. The changes for DERBY-1931 - revision http://svn.apache.org/viewvc?view=revrevision=581971 were extensive enough... Probably also the doc plugin merits a second look, to see if maybe this change for DERBY-1931 merits some documentation. I don't think the core plugin needs to be regenerated for a chance to the plugins - looking at it (after unzipping, and looking at the plugin.xml with a text editor) it only contains derby.jar, derbyclient.jar, derbytools.jar, derbynet.jar, derbyrun.jar; a LICENSE, a NOTICE file, and the plugin.xml for the core plugin which only shows the jars included and the derby version (10.4.1.0). I do wonder, whether the core plugin.xml has a problem as it doesn't mention derbyrun.jar, although it is included...Maybe that was an oversight from when derbyrun.jar was added to the plugin? If we fix this, we will have to regenerate the core plugin. I think the release candidate will be soon enough for that. The doc and ui plugins of course should get generated with the correct versions in their plugin.xml files. hth Myrna
Re: [Db-derby Wiki] Update of DerbySnapshotOrRelease by DyreTjeldvoll
Andrew McIntyre [EMAIL PROTECTED] writes:
On Tue, Mar 18, 2008 at 7:16 AM, Apache Wiki [EMAIL PROTECTED] wrote:
+
+ /!\ '''Is this still necessary?'''
+
+ {{{cd tools/release
+ ant bumplastdigit}}}
+
+ /!\ '''Commit the changed version number here?'''
+
I hadn't caught this question earlier in the previous diffs to the
release wiki page.
Well, I've put those comments in there more or less as reminders to
myself, but thanks for looking at it. I was thinking about asking for a
review of the changes later, perhaps after the release...
To answer this question, the process should be:
* update version to reflect proper version for release candidate,
check it in, run svn update, so that the version reported doesn't
contain an 'M' or a range
* build release candidate, RC then reflects a specific revision in Subversion
* bump the last digit, and commit the version again so that any
further changes to the branch are reflected as not being in the RC
version and sysinfo reports a version that is newer than the RC
version.
Thanks :)
There is also a question on the page about running maintversion2props,
I'm pretty sure the build.xml in tools/release handles this, no?
I think so. At least I noticed that if I deleted
maintversion.properties before building the release artifacts, it seemed
to reappear as part of the build process.
Dyre, if you didn't need to run it separately, please remove the
mention of this tool from the page.
Will do. Thanks.
--
dt
Re: Eclipse plugin
Myrna van Lunteren [EMAIL PROTECTED] writes: I do wonder, whether the core plugin.xml has a problem as it doesn't mention derbyrun.jar, although it is included...Maybe that was an oversight from when derbyrun.jar was added to the plugin? If we fix this, we will have to regenerate the core plugin. I think the release candidate will be soon enough for that. Now that I've been through the process I don' mind spinning another beta :) Just let me know... The doc and ui plugins of course should get generated with the correct versions in their plugin.xml files. -- dt
Re: Eclipse plugin
On 3/19/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Myrna van Lunteren [EMAIL PROTECTED] writes: I do wonder, whether the core plugin.xml has a problem as it doesn't mention derbyrun.jar, although it is included...Maybe that was an oversight from when derbyrun.jar was added to the plugin? If we fix this, we will have to regenerate the core plugin. I think the release candidate will be soon enough for that. Now that I've been through the process I don' mind spinning another beta :) Just let me know... -- dt I really don't think it's necessary to make another beta. I tried to figure out where this change of including derbyrun.jar came from, and it's because in the top level build.xml we're specifying derby*.jar (excluding derbyLocale* and derbyTesting.jar). So when derbyrun was invented, it got included automatically. However, the core plugin.xml gets generated during the build by org.apache.derbyBuild.eclipse.DerbyEclipsePlugin (source under java/build), which doesn't add derbyrun to the list of jars. I'm not sure if we should exclude derbyrun.jar from the build process so it doesn't get into the core plugin, or add it to the core plugin's plugin.xml. The plugins were not designed to have it in, the plugin documentation probably doesn't mention it. But maybe it should be included and documented. I'll do some further thinking about how one would use derbyrun.jar from within eclipse, if anyone has an opinion? For now, I'm inclined to think we should exclude derbyrun.jar in build.xml... Myrna
[jira] Updated: (DERBY-2892) Closing a resultset after retrieving a large 32665 bytes value with Network Server does not release locks
[ https://issues.apache.org/jira/browse/DERBY-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-2892: -- Affects Version/s: 10.3.2.1 Fix Version/s: (was: 10.2.2.1) 10.4.0.0 10.3.2.2 Closing a resultset after retrieving a large 32665 bytes value with Network Server does not release locks --- Key: DERBY-2892 URL: https://issues.apache.org/jira/browse/DERBY-2892 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0, 10.3.1.4, 10.3.2.1 Environment: JDK: build 1.6.0_01-b06 (WinXP Gentoo/SuSE) Hardware: Intel x86 Client/Server environment Reporter: Thomas Niessen Assignee: Øystein Grøvlen Priority: Critical Fix For: 10.3.2.2, 10.4.0.0 Attachments: derby-2892.diff, DERBY-2892_07_10_07_try1_diff.txt, DERBY-2892_07_10_07_try1_stat.txt, DERBY-2892_07_13_07_try2_diff.txt, DERBY-2892_07_13_07_try2_stat.txt, derby-2892firstshot.diff, protocolErrorRepro.zip This is the same issue as DERBY-255 (https://issues.apache.org/jira/browse/DERBY-255). The test attached to DERBY-255 shows the locks being not released. Everything is fine when using Derby 10.1.3.1 . I would think it's a regression bug. Output from sysinfo: -- Java-Informationen -- Java-Version: 1.6.0_01 Java-Anbieter: Sun Microsystems Inc. Java-Home: C:\work\applications\development\java\jdk1.6u1-SE\jre Java-Klassenpfad: C:\work\applications\development\derby-10.2.2.0/lib/derby.jar;C:\work\applications\development\derby- 0.2.2.0/lib/derbynet.jar;C:\work\applications\development\derby-10.2.2.0/lib/derbyclient.jar;C:\work\applications\devel pment\derby-10.2.2.0/lib/derbytools.jar Name des Betriebssystems: Windows XP Architektur des Betriebssystems: x86 Betriebssystemversion: 5.1 Java-Benutzername: thomas.niessen Java-Benutzerausgangsverzeichnis: C:\Dokumente und Einstellungen\thomas.niessen Java-Benutzerverzeichnis: C:\work\applications\development\derby-10.2.2.0 java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby-Informationen JRE - JDBC: Java SE 6 - JDBC 4.0 [C:\work\applications\development\derby-10.2.2.0\lib\derby.jar] 10.2.2.0 - (485682) [C:\work\applications\development\derby-10.2.2.0\lib\derbytools.jar] 10.2.2.0 - (485682) [C:\work\applications\development\derby-10.2.2.0\lib\derbynet.jar] 10.2.2.0 - (485682) [C:\work\applications\development\derby-10.2.2.0\lib\derbyclient.jar] 10.2.2.0 - (485682) -- - Informationen zur Lõndereinstellung - Aktuelle Lõndereinstellung: [Deutsch/Deutschland [de_DE]] Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [cs] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [de_DE] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [es] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [fr] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [hu] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [it] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ja_JP] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ko_KR] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [pl] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [pt_BR] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ru] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [zh_CN] Version: 10.2.2.0 - (485682) Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [zh_TW] Version: 10.2.2.0 - (485682) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3536) specialCollation() and noSpecialCollation() in TableFunctionTest fail with weme6.1.
[ https://issues.apache.org/jira/browse/DERBY-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3536: - Attachment: derby-3536-01-aa-decimalCast.diff Hi Army, Thanks for logging this bug. Could you test-drive the attached patch (derby-3536-01-aa-decimalCast.diff) and see if it fixes the problem? Thanks. specialCollation() and noSpecialCollation() in TableFunctionTest fail with weme6.1. --- Key: DERBY-3536 URL: https://issues.apache.org/jira/browse/DERBY-3536 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: A B Priority: Minor Attachments: derby-3536-01-aa-decimalCast.diff The specialCollation() and noSpecialCollation() fixtures in TableFunctionTest fail when run with weme6.1. I have not explicitly confirmed but it looks like this may be related to svn # 636004. The stack trace is: noSpecialCollation(o.a.dTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at o.a.d.impl.jdbc.Util.generateCsSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedConnection.handleException(Unknown Source) at o.a.d.impl.jdbc.ConnectionChild.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.next(Unknown Source) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.allLegalDatatypesVTIResults(TableFunctionTest.java:1178) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:921) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at o.a.dTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) Caused by: ERROR 22005: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.iapi.error.StandardException.newException(Unknown Source) at o.a.d.iapi.types.DataType.dataTypeConversion(Unknown Source) at o.a.d.iapi.types.DataType.getObject(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.cast(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at o.a.d.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) Comments from RIck on derby-dev (in response to DERBY-3341 inquiry): The handling of DECIMAL on the small device platform is different. The test may need some special logic so that it calls the correct method for the small device environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3373) SQL distinct and order by needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3373: -- Fix Version/s: 10.4.0.0 I added 10.4 as a fix version. 10.3.2.2 is already listed, so if possible, I think it would be good to merge the fix to 10.3 as well. SQL distinct and order by needed together - Key: DERBY-3373 URL: https://issues.apache.org/jira/browse/DERBY-3373 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.2.1 Environment: Solaris Dev Express, Java 5 Reporter: Thomas Vatter Assignee: Bryan Pendleton Priority: Blocker Fix For: 10.3.2.2, 10.4.0.0 Attachments: allowExpressions.diff, mergeWith2351.diff I am pasting here the communication from the mailinglist. I am having a blocking and large problem with it because I have to make a release that needs the specified SQL query. tom_ wrote: The errormessage is The ORDER BY clause may not specify an expression, since the query specifies DISTINCT [Error Code: 2] [SQL State: 4287A] The statement is select distinct t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 from t1, t2, t3 where ... order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) Dyre.Tjeldvoll wrote: tom_ [EMAIL PROTECTED] writes: I am using disctinct because of some self-joins and also needed to add an order by clause. An error is shown. Is it not possible to use distinct and order by together? I think it is allowed. Executing select distinct * from sys.systables order by tablename; in ij works just fine. Could you show the error message you get, and perhaps what the table looks like? -- dt « [hide part of quote] Hi Tom - I see what you mean using the demo DB toursDB: ij select * from airlines order by lower(airline_full); A|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT |BUSINESS_LEVEL_FACTOR |FIRSTCLASS_LEVEL_FACT|ECONOMY_SE|BUSINESS_S|FIRSTCLASS --- AA|Amazonian Airways |0.18 |0.03 |0.5 |1.5 |20 |10 |5 US|Union Standard Airlines |0.19 |0.05 |0.4 |1.6 |20 |10 |5 2 rows selected ij select distinct * from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij select distinct airline_full from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij I didn't find a JIRA enhancement to remove this restriction. I suggest you file an Enhancement request to remove the restriction reported by ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3545) NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation
[ https://issues.apache.org/jira/browse/DERBY-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580394#action_12580394 ] Rick Hillegas commented on DERBY-3545: -- I have not been able to reproduce this problem yet. This is my environment: Java 5 Mac OS X both sane and insane Derby jars This is the ant command I run: ant -Dderby.junit.testclass=org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest junit-single NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation - Key: DERBY-3545 URL: https://issues.apache.org/jira/browse/DERBY-3545 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.1.0, 10.5.0.0 Environment: IBM 1.5 - linux - insane jars Reporter: Daniel John Debrunner Attachments: TEST-org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.xml Running the tests through ant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3545) NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation
[ https://issues.apache.org/jira/browse/DERBY-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580396#action_12580396 ] Daniel John Debrunner commented on DERBY-3545: -- ant junit-clean junit-all-codeline-jars NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation - Key: DERBY-3545 URL: https://issues.apache.org/jira/browse/DERBY-3545 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.1.0, 10.5.0.0 Environment: IBM 1.5 - linux - insane jars Reporter: Daniel John Debrunner Attachments: TEST-org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.xml Running the tests through ant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3162) Create a framework for replication tests
[ https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580397#action_12580397 ] Dyre Tjeldvoll commented on DERBY-3162: --- This issue has 10.5 as fixversion. Should it not be 10.4? Create a framework for replication tests Key: DERBY-3162 URL: https://issues.apache.org/jira/browse/DERBY-3162 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Ole Solberg Assignee: Ole Solberg Priority: Minor Fix For: 10.5.0.0 Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt, derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt, derby-3162.3-v4d.stat.txt, derby-3162.4-v3.diff.txt, derby-3162.4-v3.stat.txt, derby-3162.5-v1.diff.txt, derby-3162.5-v1.stat.txt, derby-3162.6_v1.diff.txt, derby-3162.6_v1.stat.txt Handle - starting and stopping Derby servers to have the master and slave replication roles, - doing administrative commands like startreplication, startslave, stopreplication, failover, - performing consistency checks on the slave vs. the master, - running load clients against master and slave in the various states of replication, - provoking error situations on master and slave, and network, - ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-3169: - Attachment: DERBY-3169-5.zip DERBY-3169-5.diff Thanks, Jørgen, for the comment. Here are new diff and zip files with the one-word change (DERBY-3169-5.diff and DERBY-3169-5.zip). I wonder if it would make sense to commit these now, without resolving the issue, just so any subsequent changes could be incremental? (I haven't yet learned how to commit, so someone else would need to do this.) I can see that implementing the SYSCS_UTIL.SYSCS_PREPARE_REPLICATION procedure would require only a new file in the Reference Manual and some changes to the Starting and running replication topic of the Admin Guide. There was also something in the comments to DERBY-3552 about a possible need for documentation concerning jar files, but I don't quite understand this issue yet so I'm not sure what would be involved. Add documentation for replication - Key: DERBY-3169 URL: https://issues.apache.org/jira/browse/DERBY-3169 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Kim Haase Attachments: DERBY-3169-2.diff, DERBY-3169-2.stat, DERBY-3169-2.zip, DERBY-3169-3.diff, DERBY-3169-3.stat, DERBY-3169-3.zip, DERBY-3169-4.diff, DERBY-3169-4.zip, DERBY-3169-5.diff, DERBY-3169-5.zip, DERBY-3169.diff, DERBY-3169.stat, DERBY-3169.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-1977) Make it possible to run JUnit tests with the GUI runners
[ https://issues.apache.org/jira/browse/DERBY-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll closed DERBY-1977. - Resolution: Cannot Reproduce This has been fixed at some point, but I don't know by which issue, so I can't close as duplicate. Make it possible to run JUnit tests with the GUI runners Key: DERBY-1977 URL: https://issues.apache.org/jira/browse/DERBY-1977 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.2.1.6 Reporter: Dyre Tjeldvoll Kristain Waagan wrote in a message on derby-dev: The problem is that the GUI runners are using a custom classload to allow for dynamic reloading of the test classes. It defeats the getURL method in SecurityManagerSetup, seemingly by returning an empty/null (the object itself isn't null) ProtectionDomain object. This finally leads to the URL object extracted being null, which causes the NPE. A workaround is to specify the -noloading option for the runner, like this: java -classpath X junit.swingui.TestRunner -noloading org.apache.derbyTesting... If you do this, you must restart the GUI if you recompile the test classes. We should investigate this and see if we can get it working without specifying the -noloading argument. -- 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 (17 issues) Subscriber: derby-dev Key Summary DERBY-3169 Add documentation for replication https://issues.apache.org/jira/browse/DERBY-3169 DERBY-3162 Create a framework for replication tests https://issues.apache.org/jira/browse/DERBY-3162 DERBY-3382 Replication: Slave must inform master if DBs are out of sync. https://issues.apache.org/jira/browse/DERBY-3382 DERBY-3527 The slave will not notice that a network cable is unplugged and will therefore reject failover/stopSlave commands https://issues.apache.org/jira/browse/DERBY-3527 DERBY-3447 Shutdown on a database without stopping replication hangs https://issues.apache.org/jira/browse/DERBY-3447 DERBY-3379 No Current connection on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing https://issues.apache.org/jira/browse/DERBY-3379 DERBY-3542 New ROW_NUMBER function topic needs a few minor fixes https://issues.apache.org/jira/browse/DERBY-3542 DERBY-3474 update unique constraint sections of refrence manual https://issues.apache.org/jira/browse/DERBY-3474 DERBY-3445 Make it easier to use the EMMA tool to measure the code coverage of the Derby testing https://issues.apache.org/jira/browse/DERBY-3445 DERBY-3310 ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions https://issues.apache.org/jira/browse/DERBY-3310 DERBY-3494 Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode https://issues.apache.org/jira/browse/DERBY-3494 DERBY-3460 SQL roles: patch to mask off roles on 10.4 release branch https://issues.apache.org/jira/browse/DERBY-3460 DERBY-3327 SQL roles: Implement authorization stack (and SQL session context to hold it) https://issues.apache.org/jira/browse/DERBY-3327 DERBY-2871 XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. https://issues.apache.org/jira/browse/DERBY-2871 DERBY-3409 Remove JDBC 2.0-specific topics from Reference Manual and merge implementation notes as needed https://issues.apache.org/jira/browse/DERBY-3409 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-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
[jira] Closed: (DERBY-1654) Calling Connection.commit() does not throw exception in autocommit mode
[ https://issues.apache.org/jira/browse/DERBY-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll closed DERBY-1654. - Resolution: Won't Fix The issue with existing applications and usability undesirable to fix this. Calling Connection.commit() does not throw exception in autocommit mode --- Key: DERBY-1654 URL: https://issues.apache.org/jira/browse/DERBY-1654 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.3.1 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: simple.java The jdbc spec (don't know chapter and verse) states that an attempt to call Connection.commit() when Connection.getAutoCommit() is true, must throw an exception. The attached repro (simple.java) runs fine with Derby (and Postgres), but fails with MySQL: [EMAIL PROTECTED]/java$ java -cp $CLASSPATH:. simple com.mysql.jdbc.Driver 'jdbc:mysql://localhost/joindb' joinuser joinpass foo4 java.sql.SQLException: Can't call commit when autocommit=true at com.mysql.jdbc.Connection.commit(Connection.java:2161) at simple.main(simple.java:17) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (DERBY-3169) Add documentation for replication
Kim Haase (JIRA) wrote: I haven't yet learned how to commit, so someone else would need to do this. Seems like a good time to learn then! http://wiki.apache.org/db-derby/DerbyCommitHowTo Dan.
Re: Release notes for Wrong Results bug...
Dyre Tjeldvoll (JIRA) wrote: This issue has fix version 10.4 and is marked with either 'Release note needed' or 'Existing application impact', but does not have a releaseNote.html attached to it. Should it? I think Wrong Results bugs like DERBY-3023, DERBY-2351, and DERBY-3301 have Existing application impact checked because the solutions to those bugs could change the query results seeen by existing apps--esp. we're now getting correct results where we were getting incorrect results before. It seems like having a release note for such cases would be worthwhile so that users who see different results after upgrading to 10.4 can look at the release notes to get an idea of what may have caused the change. Some example release notes for wrong results bugs can be found for DERBY-2256 and DERBY-1852; the latter is more detailed than the former. Note, though, that someone on the list mentioned a long while ago that use of the term may now return different results in the Summary of Change section is not desirable since different does not imply correct. (I don't have the thread handy.) Just changing different to correct doesn't help because then it would say we *may* now return correct results, which isn't good. Removing may and just saying now return correct results is also a tad undesirable as it seems to suggest that the types of queries in question always returned incorrect results before, which isn't necessarily true (sometimes it depends on the data). But maybe that's the best way to go... Army
[jira] Assigned: (DERBY-3373) SQL distinct and order by needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll reassigned DERBY-3373: - Assignee: Dyre Tjeldvoll (was: Bryan Pendleton) SQL distinct and order by needed together - Key: DERBY-3373 URL: https://issues.apache.org/jira/browse/DERBY-3373 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.2.1 Environment: Solaris Dev Express, Java 5 Reporter: Thomas Vatter Assignee: Dyre Tjeldvoll Priority: Blocker Fix For: 10.3.2.2, 10.4.0.0 Attachments: allowExpressions.diff, mergeWith2351.diff I am pasting here the communication from the mailinglist. I am having a blocking and large problem with it because I have to make a release that needs the specified SQL query. tom_ wrote: The errormessage is The ORDER BY clause may not specify an expression, since the query specifies DISTINCT [Error Code: 2] [SQL State: 4287A] The statement is select distinct t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 from t1, t2, t3 where ... order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) Dyre.Tjeldvoll wrote: tom_ [EMAIL PROTECTED] writes: I am using disctinct because of some self-joins and also needed to add an order by clause. An error is shown. Is it not possible to use distinct and order by together? I think it is allowed. Executing select distinct * from sys.systables order by tablename; in ij works just fine. Could you show the error message you get, and perhaps what the table looks like? -- dt « [hide part of quote] Hi Tom - I see what you mean using the demo DB toursDB: ij select * from airlines order by lower(airline_full); A|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT |BUSINESS_LEVEL_FACTOR |FIRSTCLASS_LEVEL_FACT|ECONOMY_SE|BUSINESS_S|FIRSTCLASS --- AA|Amazonian Airways |0.18 |0.03 |0.5 |1.5 |20 |10 |5 US|Union Standard Airlines |0.19 |0.05 |0.4 |1.6 |20 |10 |5 2 rows selected ij select distinct * from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij select distinct airline_full from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij I didn't find a JIRA enhancement to remove this restriction. I suggest you file an Enhancement request to remove the restriction reported by ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3373) SQL distinct and order by needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll reassigned DERBY-3373: - Assignee: Bryan Pendleton (was: Dyre Tjeldvoll) Sorry. I changed the wrong issue. Changing the assignee back to Bryan. SQL distinct and order by needed together - Key: DERBY-3373 URL: https://issues.apache.org/jira/browse/DERBY-3373 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.2.1 Environment: Solaris Dev Express, Java 5 Reporter: Thomas Vatter Assignee: Bryan Pendleton Priority: Blocker Fix For: 10.3.2.2, 10.4.0.0 Attachments: allowExpressions.diff, mergeWith2351.diff I am pasting here the communication from the mailinglist. I am having a blocking and large problem with it because I have to make a release that needs the specified SQL query. tom_ wrote: The errormessage is The ORDER BY clause may not specify an expression, since the query specifies DISTINCT [Error Code: 2] [SQL State: 4287A] The statement is select distinct t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 from t1, t2, t3 where ... order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) Dyre.Tjeldvoll wrote: tom_ [EMAIL PROTECTED] writes: I am using disctinct because of some self-joins and also needed to add an order by clause. An error is shown. Is it not possible to use distinct and order by together? I think it is allowed. Executing select distinct * from sys.systables order by tablename; in ij works just fine. Could you show the error message you get, and perhaps what the table looks like? -- dt « [hide part of quote] Hi Tom - I see what you mean using the demo DB toursDB: ij select * from airlines order by lower(airline_full); A|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT |BUSINESS_LEVEL_FACTOR |FIRSTCLASS_LEVEL_FACT|ECONOMY_SE|BUSINESS_S|FIRSTCLASS --- AA|Amazonian Airways |0.18 |0.03 |0.5 |1.5 |20 |10 |5 US|Union Standard Airlines |0.19 |0.05 |0.4 |1.6 |20 |10 |5 2 rows selected ij select distinct * from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij select distinct airline_full from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij I didn't find a JIRA enhancement to remove this restriction. I suggest you file an Enhancement request to remove the restriction reported by ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3496) CallableStatement with output parameter leaves cursor open after execution
[ https://issues.apache.org/jira/browse/DERBY-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll reassigned DERBY-3496: - Assignee: Dyre Tjeldvoll CallableStatement with output parameter leaves cursor open after execution -- Key: DERBY-3496 URL: https://issues.apache.org/jira/browse/DERBY-3496 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.3.2.2, 10.4.0.0 Attachments: junit-repro.diff When executing a CallableStatement which has an output parameter, the language result set is left open and makes subsequent calls to Connection.setTransactionIsolation() fail with ERROR X0X03: Invalid transaction state - held cursor requires same isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3554) Change Collation test to run DatabaseMetaDataTest, BatchUpdateTest,GroupByExpressionTest, and UpdateableResultSetTest for only one locale
Change Collation test to run DatabaseMetaDataTest, BatchUpdateTest,GroupByExpressionTest, and UpdateableResultSetTest for only one locale - Key: DERBY-3554 URL: https://issues.apache.org/jira/browse/DERBY-3554 Project: Derby Issue Type: Improvement Components: Newcomer, Test Affects Versions: 10.5.0.0 Reporter: Kathey Marsden Priority: Minor Currently CollationTest runs DatabaseMetaDataTest, BatchUpdateTest,GroupByExpressionTest, and UpdateableResultSetTest for multiple locales and territory based collation. It would be sufficient for these to run with a single locale and would save some time running tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3375) Localize new error messages added in 10.3
[ https://issues.apache.org/jira/browse/DERBY-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll reassigned DERBY-3375: - Assignee: Dyre Tjeldvoll Localize new error messages added in 10.3 - Key: DERBY-3375 URL: https://issues.apache.org/jira/browse/DERBY-3375 Project: Derby Issue Type: Improvement Components: Localization Affects Versions: 10.3.2.1 Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.4.0.0 Attachments: CheckMessages.java, checkMessages.sql, derby-3375.diff, derby-3375.master.v1.diff, derby-3375.v2.diff, drda_messages.zip, engine_messages.zip New error messages added in 10.3 have not been localized. Should translate these into as many languages as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3375) Localize new error messages added in 10.3
[ https://issues.apache.org/jira/browse/DERBY-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll closed DERBY-3375. - Resolution: Fixed I'm closing this since the original problem has been fixed. If someone wants to pick up the task of changing the localization system, I think it would be good to create a separate Jira for that. Localize new error messages added in 10.3 - Key: DERBY-3375 URL: https://issues.apache.org/jira/browse/DERBY-3375 Project: Derby Issue Type: Improvement Components: Localization Affects Versions: 10.3.2.1 Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.4.0.0 Attachments: CheckMessages.java, checkMessages.sql, derby-3375.diff, derby-3375.master.v1.diff, derby-3375.v2.diff, drda_messages.zip, engine_messages.zip New error messages added in 10.3 have not been localized. Should translate these into as many languages as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580423#action_12580423 ] Mamta A. Satoor commented on DERBY-3320: In DVF.setLocale, the Collator object gets created whether we are dealing with territory based database or not. If the database is not territory based, then the Collator object never gets used. But if it is a territory based database, then Store might use the Collator object if it needs to database recovery. I think we can check if the Collator object can be created or not for the given locale irrespective of whether it is territory based db or UCS_BASIC db. So, I will go ahead and do the check and not worry about whether it is boot/create time and whether we are dealing with territory based db or not. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-481) implement SQL generated columns
[ https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-481: Attachment: GeneratedColumns.html Attaching a first rev of a functional spec for this features: GeneratedColumns.html implement SQL generated columns --- Key: DERBY-481 URL: https://issues.apache.org/jira/browse/DERBY-481 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.0.2.1 Reporter: Rick Hillegas Attachments: GeneratedColumns.html Satheesh has pointed out that generated columns, a SQL 2003 feature, would satisfy the performance requirements of Expression Indexes (bug 455). Generated columns may not be as elegant as Expression Indexes, but they are easier to implement. We would allow the following new kind of column definition in CREATE TABLE and ALTER TABLE statements: columnName GENERATED ALWAYS AS ( expression ) If expression were an indexableExpression (as defined in bug 455), then we could create indexes on it. There is no work for the optimizer to do here. The Language merely has to compute the generated column at INSERT/UPDATE time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result
[ https://issues.apache.org/jira/browse/DERBY-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580429#action_12580429 ] Bryan Pendleton commented on DERBY-2351: I agree, it should have a release note. I'll try to get one written soon. ORDER BY with expression with distinct in the select list returns incorrect result -- Key: DERBY-2351 URL: https://issues.apache.org/jira/browse/DERBY-2351 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4 Environment: Any Reporter: Yip Ng Assignee: Bryan Pendleton Fix For: 10.3.2.2, 10.4.0.0, 10.4.1.0, 10.5.0.0 Attachments: d2351_aliasing.diff, d2351_aliasing.diff, d2351_aliasing_checkQualifiedName.diff, derby_2351.diff, derby_2351_v2.diff, modifySynonymResults.diff, reproTests.diff When distinct is in the select list and the query has order by with expression, the resultset produced contains an additional column. ij create table t1 (c1 int, c2 varchar(10)) 0 rows inserted/updated/deleted ij insert into t1 values (1,'a'),(2,'b'),(3,'c'); 3 rows inserted/updated/deleted select distinct c1, c2 from t1 order by c1; C1 |C2 -- 1 |a 2 |b 3 |c 3 rows selected ij select distinct c1, c2 from t1 order by c1+1; C1 |C2|3 =returns 3 columns, incorrect result returned -- 1 |a |2 2 |b |3 3 |c |4 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Fix version for unassigned issues
I see that in the past unsassigned Jira issues have had their Fix-version removed. This seems reasonable to me, but I'd like to confirm that this is our policy before I bulk-remove fix-version for unassigned issues. There are currently 13 such issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10594fixfor=10992fixfor=12311972fixfor=12311950fixfor=12312251fixfor=12312215fixfor=12312885fixfor=12312540fixfor=12313072fixfor=12313010fixfor=12312083fixfor=-3fixfor=12312876fixfor=12312590fixfor=12312027fixfor=11187fixfor=12311953fixfor=12310615fixfor=10993fixfor=10991fixfor=10920resolution=-1assigneeSelect=unassignedsorter/field=prioritysorter/order=DESC -- dt
[jira] Commented: (DERBY-3169) Add documentation for replication
[
https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580430#action_12580430
]
V.Narayanan commented on DERBY-3169:
Thank you for the excellent work you have been doing for replication
documentation Kim.
I can see that implementing the SYSCS_UTIL.SYSCS_PREPARE_REPLICATION procedure
would
require only a new file in the Reference Manual and some changes to the
Starting and
running replication topic of the Admin Guide.
You are correct in your estimation of the work required to document this stored
procedure.
This procedure would be involved only during replication startup and its
presence in the
Reference manual in the stored procedures section, and, the Admin guide section
for starting
and running replication should suffice
There was also something in the comments to DERBY-3552 about a possible need
for
documentation concerning jar files, but I don't quite understand this issue
yet so I'm not
sure what would be involved.
There are two possibilities
1) Write documentation saying that, if jars need to be installed when
replication is running for
the database the user will have to manually copy the jar files to the slave.
2) Disable jar file operations during replication, in which case we will have
to document saying that
users cannot perform jar operations when replication is running.
I am inclined towards 1) because it gives more flexibility to the user, but I
was hoping to get some more
inputs from the community in the coming days on this, which is why I have left
it open.
-
An example for installing a jar file would be like this
ij CALL SQLJ.install_jar
('myStuff.jar', 'APP.MyStuffJar', 0);
ij CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY
('derby.database.classpath', 'APP.MyStuffJar');
I found this example here http://wiki.apache.org/db-derby/DerbySQLroutines
Add documentation for replication
-
Key: DERBY-3169
URL: https://issues.apache.org/jira/browse/DERBY-3169
Project: Derby
Issue Type: Improvement
Components: Documentation
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: Kim Haase
Attachments: DERBY-3169-2.diff, DERBY-3169-2.stat, DERBY-3169-2.zip,
DERBY-3169-3.diff, DERBY-3169-3.stat, DERBY-3169-3.zip, DERBY-3169-4.diff,
DERBY-3169-4.zip, DERBY-3169-5.diff, DERBY-3169-5.zip, DERBY-3169.diff,
DERBY-3169.stat, DERBY-3169.zip
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580432#action_12580432 ] Daniel John Debrunner commented on DERBY-3320: -- That's not exactly what I meant, I was more thinking of just throwing an error when a collator was requested (ie. needed for collation) and could not be created. Thinking about it more though, that might be sometime later than create/boot. Though I'm not sure if that's a problem. Thinking about the future, a database may have many collations associated with it. Will it be a requirement that all collations are supported on the current jvm before the database can be booted? Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (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 ] Dyre Tjeldvoll closed DERBY-2658. - 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] Commented: (DERBY-2658) Convert jdbcapi/parameterMetaDataJdbc30.java to JUnit
[ https://issues.apache.org/jira/browse/DERBY-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580433#action_12580433 ] Dyre Tjeldvoll commented on DERBY-2658: --- rev 572662 merged to 10.3 in revision 638919. 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] Resolved: (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 ] Dyre Tjeldvoll resolved DERBY-2658. --- Resolution: Fixed 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] Issue Comment Edited: (DERBY-481) implement SQL generated columns
[ https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580425#action_12580425 ] rhillegas edited comment on DERBY-481 at 3/19/08 9:17 AM: -- Attaching a first rev of a functional spec for this feature: GeneratedColumns.html was (Author: rhillegas): Attaching a first rev of a functional spec for this features: GeneratedColumns.html implement SQL generated columns --- Key: DERBY-481 URL: https://issues.apache.org/jira/browse/DERBY-481 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.0.2.1 Reporter: Rick Hillegas Attachments: GeneratedColumns.html Satheesh has pointed out that generated columns, a SQL 2003 feature, would satisfy the performance requirements of Expression Indexes (bug 455). Generated columns may not be as elegant as Expression Indexes, but they are easier to implement. We would allow the following new kind of column definition in CREATE TABLE and ALTER TABLE statements: columnName GENERATED ALWAYS AS ( expression ) If expression were an indexableExpression (as defined in bug 455), then we could create indexes on it. There is no work for the optimizer to do here. The Language merely has to compute the generated column at INSERT/UPDATE time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580436#action_12580436 ] Mamta A. Satoor commented on DERBY-3320: Dan wrote Thinking about it more though, that might be sometime later than create/boot. I am not sure if that is correct, In case of recovery, store will need the collator object during boot. Based on the same thinking, in future, when a database may have many collations associated with it, we might need to make sure the all collations are supported at db boot time because they may be required during store recovery at the database boot time. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Fix version for unassigned issues
[EMAIL PROTECTED] wrote: I see that in the past unsassigned Jira issues have had their Fix-version removed. This seems reasonable to me, but I'd like to confirm that this is our policy before I bulk-remove fix-version for unassigned issues. There are currently 13 such issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10594fixfor=10992fixfor=12311972fixfor=12311950fixfor=12312251fixfor=12312215fixfor=12312885fixfor=12312540fixfor=12313072fixfor=12313010fixfor=12312083fixfor=-3fixfor=12312876fixfor=12312590fixfor=12312027fixfor=11187fixfor=12311953fixfor=12310615fixfor=10993fixfor=10991fixfor=10920resolution=-1assigneeSelect=unassignedsorter/field=prioritysorter/order=DESC Seems reasonable to me. Regards, -Rick
[jira] Commented: (DERBY-481) implement SQL generated columns
[ https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580439#action_12580439 ] Daniel John Debrunner commented on DERBY-481: - In the spec: We rename the sqlAllowed field of RoutineAliasInfo and borrow one of its bits to encode whether a routine is DETERMINISTIC. RoutineAliasInfo already has a field set up for expansion, I think we can use this in a smart way instead of making a single field handle multiple meanings (less clear). I've always been planning to add all the possible future options for routines into RoutineAliasInfo, I'd be willing to handle that portion for this improvement. implement SQL generated columns --- Key: DERBY-481 URL: https://issues.apache.org/jira/browse/DERBY-481 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.0.2.1 Reporter: Rick Hillegas Attachments: GeneratedColumns.html Satheesh has pointed out that generated columns, a SQL 2003 feature, would satisfy the performance requirements of Expression Indexes (bug 455). Generated columns may not be as elegant as Expression Indexes, but they are easier to implement. We would allow the following new kind of column definition in CREATE TABLE and ALTER TABLE statements: columnName GENERATED ALWAYS AS ( expression ) If expression were an indexableExpression (as defined in bug 455), then we could create indexes on it. There is no work for the optimizer to do here. The Language merely has to compute the generated column at INSERT/UPDATE time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580442#action_12580442 ] Daniel John Debrunner commented on DERBY-3320: -- I don't think store needs the collator if there is no recovery to perform (e.g. clean shutdown previously), so that's what I meant by might be sometime later. So I'm saying if the database has tables with three collations A,B,C and the current vm only supports A,C, then if recovery does not touch any table with B, then why not let the database boot. If recovery needed B then an exception would be thrown and the database would fail to boot. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-481) implement SQL generated columns
[ https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580443#action_12580443 ] Rick Hillegas commented on DERBY-481: - Thanks, Dan. That would be great. implement SQL generated columns --- Key: DERBY-481 URL: https://issues.apache.org/jira/browse/DERBY-481 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.0.2.1 Reporter: Rick Hillegas Attachments: GeneratedColumns.html Satheesh has pointed out that generated columns, a SQL 2003 feature, would satisfy the performance requirements of Expression Indexes (bug 455). Generated columns may not be as elegant as Expression Indexes, but they are easier to implement. We would allow the following new kind of column definition in CREATE TABLE and ALTER TABLE statements: columnName GENERATED ALWAYS AS ( expression ) If expression were an indexableExpression (as defined in bug 455), then we could create indexes on it. There is no work for the optimizer to do here. The Language merely has to compute the generated column at INSERT/UPDATE time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580445#action_12580445 ] Mamta A. Satoor commented on DERBY-3320: So, seems like there could be 2 approaches here. During the boot, if the access to Collator object is required, then verify at that time that the Collator object can be created for the given locale. Once, the recovery/boot is over, 1)right before leaving the boot process, make sure that the Collator object can be created if it has not already been created. This would mean that if the database has tables with three different collations, then all those Collator objects should be supported by JVM once the boot process is over. 2)wait until the first access to Collator object and verify that Collator object can be instantiated. So, user may not find until much later in the database session(when they actually need to use the Collator object) that the required Collator object is not available. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Feature description in release notes
The release notes should include a brief description of new features. This is what I currently have for 10.4, (based on descriptions from the 10.4 Wiki (http://wiki.apache.org/db-derby/DerbyTenFourRelease#head-7b1576a303d753868f1f62423ac5cbbd8bc78dcc)): ul liSQL OLAP functionality. Features T611./li liUnique constraints on nullable columns. Feature T591./li liAsynchronous replication with basic fail-over./li liVTI Table Functions./li liJMX management interface./li liSQL bracketed comments (/*..*/) Feature T351./li liij continuation marker. interactive ij shows prompt until ;/li liA JDBC statement object cache in the client driver./li liCache the isolation level and the current schema in the client driver./li /ul Please review the descripton of any feature that you have worked on, and give me feedback. Thanks, -- Dyre Tjeldvoll
Re: Feature description in release notes
liSQL OLAP functionality. Features T611./li This is too broad, I'm afraid. The only OLAP feature we completed for 10.4 was the ROW_NUMBER feature, DERBY-2998. As far as text describing the feature, can the first few paragraphs of http://wiki.apache.org/db-derby/OLAPRowNumber be used? thanks, bryan
[jira] Resolved: (DERBY-3525) Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes
[ https://issues.apache.org/jira/browse/DERBY-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3525. --- Resolution: Fixed Fix Version/s: 10.5.0.0 10.4.1.0 10.3.2.2 Merged to 10.4 and 10.3, marking this issue resolved. Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes -- Key: DERBY-3525 URL: https://issues.apache.org/jira/browse/DERBY-3525 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.5.0.0 Reporter: Knut Anders Hatlen Assignee: Kathey Marsden Priority: Minor Fix For: 10.3.2.2, 10.4.1.0, 10.5.0.0 Attachments: derby-3525_diff.txt BrokeredConnection has a method called getJDBCLevel() whose only purpose is to provide a value that can be stored in BrokeredStatement.jdbcLevel. This field is only used once, in BrokeredStatement.createDuplicateStatement(): if (jdbcLevel == 2) newStatement = conn.createStatement(resultSetType, resultSetConcurrency); else newStatement = conn.createStatement(resultSetType, resultSetConcurrency, resultSetHoldability); Since getJDBCLevel() only returns 2 if Java version 1.3 is used, and Derby doesn't support Java 1.3 any more, BrokeredConnection.getJDBCLevel() and BrokeredStatement.jdbcLevel could be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment
[ https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580454#action_12580454 ] Kathey Marsden commented on DERBY-3513: --- After running with the test fix for an extendend period of time, the user saw the NullPointerException with the proposed patch, so I won't be committing the change to 10.1. NullPointerException in newBrokeredStatement in app server environment -- Key: DERBY-3513 URL: https://issues.apache.org/jira/browse/DERBY-3513 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.3.2 Environment: Java Version:1.5.0 Java Vendor: IBM Corporation OS name: Linux OS architecture: x86 OS version: 2.6.9-55.ELsmp Reporter: Kathey Marsden Assignee: Kathey Marsden Attachments: derby-3513_diff.txt User reports in an app server environment an intermittent NullPointerException with the 10.1 trace: R java.lang.NullPointerException org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448) ...org.apache.derby.jdbc.XAStatementControl.init(XAStatementControl.java:62) ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827) org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296) [snip user trace] The code at line 448 is simply: return new BrokeredStatement(statementControl, getJDBCLevel()); so not much room for an NPE there. I added println statements to identify the state values and where the NPE is actually occurring but that seemed to make the problem go away. It may be a JIT issue. I gave them the fix for DERBY-2142 and that did not correct the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-481) implement SQL generated columns
[ https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580458#action_12580458 ] Rick Hillegas commented on DERBY-481: - This feature was introduced to the SQL Standard in 2003. There it is called T175. Here is some information on what other databases do: DB2 - Appears to implement the full language for T175. Oracle - Does not appear to implement T175. However, some similar functionality is available. Although Oracle does not support generated columns, a function-based index can be used to index on the result of an expression according to http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/ap_standard_sql004.htm Postgres - Does not appear to implement T175. However, according to section 5.2 of the Postgres 8.3 reference manual, it appears that you can declare the DEFAULT value of a column to be computed by an expression which can contain functions. MySQL - According to section 12.1.10 of the MySQL 6.0 reference manual, MySQL only allows constants and CURRENT_TIMESTAMP as default values for columns. implement SQL generated columns --- Key: DERBY-481 URL: https://issues.apache.org/jira/browse/DERBY-481 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.0.2.1 Reporter: Rick Hillegas Attachments: GeneratedColumns.html Satheesh has pointed out that generated columns, a SQL 2003 feature, would satisfy the performance requirements of Expression Indexes (bug 455). Generated columns may not be as elegant as Expression Indexes, but they are easier to implement. We would allow the following new kind of column definition in CREATE TABLE and ALTER TABLE statements: columnName GENERATED ALWAYS AS ( expression ) If expression were an indexableExpression (as defined in bug 455), then we could create indexes on it. There is no work for the optimizer to do here. The Language merely has to compute the generated column at INSERT/UPDATE time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3320: -- I think it is reasonable in the current system to check at create database time and throw an error then rather than wait until a table with a user char column is created. But for an existing db I do think it is ok to delay the check until the actual use of the Collator, if we can make the error somewhat obvious to the user what is going on. Do test that the error makes it to the user if we fail in recovery as there have been problems in the past with errors during boot getting eaten and the user just gets a could not boot message with module startup failure. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (DERBY-3169) Add documentation for replication
Thanks for the info, Dan -- I will study it. Rick Hillegas had asked me for some information so he could set up an apache.org account for me (I guess this would be separate from my JIRA login), so I've been waiting to hear back on that before I went any further. Kim Daniel John Debrunner wrote: Kim Haase (JIRA) wrote: I haven't yet learned how to commit, so someone else would need to do this. Seems like a good time to learn then! http://wiki.apache.org/db-derby/DerbyCommitHowTo Dan.
beta build version
I noticed the beta build version has an 'M' [C:\testcompat\jars\derby.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbytools.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbynet.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbyclient.jar] 10.4.1.0 beta - (637204M) -- not a big deal for beta, but for the release, it would be good to make sure all changes are checked in before the build. Kathey
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580468#action_12580468 ] Kim Haase commented on DERBY-3169: -- Thanks very much, Narayanan -- that should give me enough to work with when the decision is made. I'll stay tuned. Add documentation for replication - Key: DERBY-3169 URL: https://issues.apache.org/jira/browse/DERBY-3169 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Kim Haase Attachments: DERBY-3169-2.diff, DERBY-3169-2.stat, DERBY-3169-2.zip, DERBY-3169-3.diff, DERBY-3169-3.stat, DERBY-3169-3.zip, DERBY-3169-4.diff, DERBY-3169-4.zip, DERBY-3169-5.diff, DERBY-3169-5.zip, DERBY-3169.diff, DERBY-3169.stat, DERBY-3169.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3536) specialCollation() and noSpecialCollation() in TableFunctionTest fail with weme6.1.
[ https://issues.apache.org/jira/browse/DERBY-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3536: -- I tried the patch out on a sane classes build in the weme6.1 environment. Before the patch, just running the TableFunctionTest I got the above error in specialCollation and noSpecialCollation. After the patch it seemed to pass, but got the following message which I believe is a separate issue: .Parsing policy file: file:/C:/p4/m2/classes/org/apache/derbyTesting/functionTes ts/util/derby_tests.policy, found unexpected: permission Parsing policy file: file:/C:/p4/m2/classes/org/apache/derbyTesting/functionTest s/util/derby_tests.policy, found unexpected: permission . Time: 21.984 OK (2 tests) specialCollation() and noSpecialCollation() in TableFunctionTest fail with weme6.1. --- Key: DERBY-3536 URL: https://issues.apache.org/jira/browse/DERBY-3536 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: A B Priority: Minor Attachments: derby-3536-01-aa-decimalCast.diff The specialCollation() and noSpecialCollation() fixtures in TableFunctionTest fail when run with weme6.1. I have not explicitly confirmed but it looks like this may be related to svn # 636004. The stack trace is: noSpecialCollation(o.a.dTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at o.a.d.impl.jdbc.Util.generateCsSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedConnection.handleException(Unknown Source) at o.a.d.impl.jdbc.ConnectionChild.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.next(Unknown Source) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.allLegalDatatypesVTIResults(TableFunctionTest.java:1178) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:921) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at o.a.dTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) Caused by: ERROR 22005: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.iapi.error.StandardException.newException(Unknown Source) at o.a.d.iapi.types.DataType.dataTypeConversion(Unknown Source) at o.a.d.iapi.types.DataType.getObject(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.cast(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at o.a.d.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) Comments from RIck on derby-dev (in response to DERBY-3341 inquiry): The handling of DECIMAL on the small device platform is different. The test may need some special logic so that it calls the correct method for the small device environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580477#action_12580477
]
Mamta A. Satoor commented on DERBY-3320:
I am starting to think of the implementation for the following approach
At the db create time, we will give the error for Collator not available (if
that is the case) when the database is getting created rather than wait until a
user creates a table with char column. For the database boot time, throw the
error whenever the Collator is accessed first(ie not right towards the end of
the boot time in BasicDatabase). This first access can happen because recovery
was required during boot time or later when user has triggered access to
Collator through SQL.
With the above approach in mind, I am thinking that I will keep the changes in
DVF.setLocale(the changes shown in the patch attached to this jira entry) where
I check if we are in here for database create time and check for Collator
object and if found, put it in collatorForCharacterTypes class variable. If not
for database create time, don't even create the Collator object in
DVF.setLocale ie do not load collatorForCharacterTypes.
DVF has a method called getCharacterCollator which now will have to see if it
is dealing with territory based db, If yes, then check if
collatorForCharacterTypes is not null. If not null, then return
collatorForCharacterTypes otherwise it mean that Collator object is getting
accessed for the first time and hence check if the JVM supports it. If not,
then throw exception. If it is supported, then put the Collator object in
collatorForCharacterTypes and return collatorForCharacterTypes from
getCharacterCollator. So, as we can see, now we will have an additional check
for territory based db in getCharacterCollator to see if
collatorForCharacterTypes is null or not and if null, then verify that Collator
is supported by the JVM. Pseudo code follows
DVF.getCharacterCollator (as it is in trunk)
if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
return (RuleBasedCollator)null;
else
return collatorForCharacterTypes;
The new code for DVF.getCharacterCollator will be
if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
return (RuleBasedCollator)null;
else if (collatorForCharacterTypes == null) {
Collator object supported by JVM for
databaseLocale?
If not, throw exception
If yes, then
collatorForCharacterTypes = Collator object
return collatorForCharacterTypes;
} else
return collatorForCharacterTypes;
Database creation and boot should fail if collation=TERRITORY_BASED and the
selected locale is not supported
Key: DERBY-3320
URL: https://issues.apache.org/jira/browse/DERBY-3320
Project: Derby
Issue Type: Bug
Affects Versions: 10.4.0.0
Environment: Java ME:
Product: phoneME Advanced (phoneme_advanced_mr2-b34)
Profile: Foundation Profile Specification 1.1
Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386
GNU/Linux
Reporter: Vemund Østgaard
Assignee: Mamta A. Satoor
Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt,
DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java
A problem I've discovered when testing with the phoneME advanced platform is
that the collationtests expect other locales than Locale.US to be available
on the platform that is used for the test, and for phoneME advanced (when
compiled as foundation profile) only Locale.US is available. From the jdk1.6
javadoc of Collator.getAvailableLocales() I see that only Locale.US is
strictly required:
public static Locale[] getAvailableLocales()
Returns an array of all locales for which the getInstance methods of this
class can return localized instances. The returned array represents the union
of locales supported by the Java runtime and by installed CollatorProvider
implementations. It must contain at least a Locale instance equal to
Locale.US.
Returns:
An array of locales for which localized Collator instances are
available.
This led me to thinking about how Derby should behave if created/booted with
collation=TERRITORY_BASED and territory=some unsupported locale. I'm not
sure what the consequences could be if the database is first created on a
platform that supports whatever locale is set and later booted with one that
doesn't, or created on a platform missing support and later booted with one
Re: Eclipse plugin
My 2 cents are for not including derbyrun.jar. Since we don;t mention about how to use derbyrun.jar. May be we can include that and modify the plugin to use derbyrun.jar in the future... Manjula On 3/19/08, Myrna van Lunteren [EMAIL PROTECTED] wrote: On 3/19/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Myrna van Lunteren [EMAIL PROTECTED] writes: I do wonder, whether the core plugin.xml has a problem as it doesn't mention derbyrun.jar, although it is included...Maybe that was an oversight from when derbyrun.jar was added to the plugin? If we fix this, we will have to regenerate the core plugin. I think the release candidate will be soon enough for that. Now that I've been through the process I don' mind spinning another beta :) Just let me know... -- dt I really don't think it's necessary to make another beta. I tried to figure out where this change of including derbyrun.jar came from, and it's because in the top level build.xml we're specifying derby*.jar (excluding derbyLocale* and derbyTesting.jar). So when derbyrun was invented, it got included automatically. However, the core plugin.xml gets generated during the build by org.apache.derbyBuild.eclipse.DerbyEclipsePlugin (source under java/build), which doesn't add derbyrun to the list of jars. I'm not sure if we should exclude derbyrun.jar from the build process so it doesn't get into the core plugin, or add it to the core plugin's plugin.xml. The plugins were not designed to have it in, the plugin documentation probably doesn't mention it. But maybe it should be included and documented. I'll do some further thinking about how one would use derbyrun.jar from within eclipse, if anyone has an opinion? For now, I'm inclined to think we should exclude derbyrun.jar in build.xml... Myrna -- Thanks, Manjula.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580486#action_12580486 ] Daniel John Debrunner commented on DERBY-3320: -- The general approach looks good, though I would say all the create logic going into setLocale() really should be in DataValueFactoryImpl.boot() Then this avoids the need to change the signature of setLocale(). Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
some advice on debugging a hang in ant junitreport
I am getting a test hang pretty consistently while trying to run ant junitreport. I am pretty sure it is in some test in the main lang _Suite test, but that xml output file is 0 length in the report directory. Is there somewhere to look, or some other option to run to be able to see what tests have executed while they are executing, and such that the info will be there if I have to kill the run because it is hanging forever (or at least all weekend the last time I tried it). /mikem
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580490#action_12580490 ] Martin Zaun commented on DERBY-2109: Not much to add to the description by Dan of the user-visible changes with NetworkServer shutdown authentication, this is pretty much it. But to restate and summarize: 1) If running derby server without authentication: no backward compatibility issues. (The old command-line usage, APIs, and derby tests continue to work.) 2) If running a derby server with authentication on: a) The command-line usage of NetworkServerControl to shutdown the sever changes: java org.apache.derby.drda.NetworkServerControl shutdown results in an exception: 08004:Connection authentication failure occurred. Reason: Invalid authentication.. The remedy is to provide credentials: java org.apache.derby.drda.NetworkServerControl shutdown -user user -password password b) The NetworkServerControl API usage to programatically shutdown a server changes: NetworkServerControl nsc = new NetworkServerControl(); nsc.shutdown(); results in a java.sql.SQLException: Connection authentication failure occurred. Reason: Invalid authentication.. The remedy is provide credentials to the NetworkServerControl constructor: NetworkServerControl nsc = new NetworkServerControl(user, password); nsc.shutdown(); c) Note that there is an edge case of b), which the current implementation only addresses poorly: NetworkServerControl nsc = new NetworkServerControl(); nsc.start(console); ... nsc.shutdown(); currently fails with above's SQLException. This is because of an asymmetrie we currently have: we don't require credentials when bringing up a server but we do require them when shutting down. There is an easy workaround, however: NetworkServerControl nsc = new NetworkServerControl(); nsc.start(console); ... NetworkServerControl nscauth = new NetworkServerControl(user, password); nscauth.shutdown(); d) If users have their own tests that use derby's junit test framework, they'll have to use a test decorator that takes user credential arguments. e) I'm not sure if users can programatically use derby's NetworkServerControlImpl (!) class to shutdown the server, but if so, they'll have to use an instance that has been constructed with user credential arguments, analog to b). One more item is a not a backward compatibility issue: When running with authentication on, I think the server already requires user credential in connection URLs, for example: connect 'jdbc:derby://localhost:1527/;shutdown=true'; fails but connect 'jdbc:derby://localhost:1527/;shutdown=true;user=user;password=password'; succeeds in 10.3 already. I don't have a strong opinion whether the shutdown authentication feature should be bundled with shutdown authorization checks later or not, but it would be nice to have a better solution for 2c). System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, DERBY-2109-12.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580497#action_12580497
]
Mamta A. Satoor commented on DERBY-3320:
I might not be understanding the boot handshake correctly but the signature of
the boot method in DVF is as follows
public void boot(boolean create, Properties properties) throws
StandardException
BasicDatabase.boot has gotten the Locale required for the db through the
following code
if (create)
{
if (startParams.getProperty(Property.CREATE_WITH_NO_LOG) ==
null)
startParams.put(Property.CREATE_WITH_NO_LOG, true);
String localeID =
startParams.getProperty(org.apache.derby.iapi.reference.Attribute.TERRITORY);
if (localeID == null) {
localeID = Locale.getDefault().toString();
}
databaseLocale = monitor.setLocale(startParams, localeID);
} else {
databaseLocale = monitor.getLocale(this);
}
And then BasicDatabase.boot boots DVF and calls DVF.setLocale so that it can
pass the locale object that it has determined to DVF. It looks like there is no
way to pass that locale info through the boot machinery that we already have in
place. So, if we want DVF.boot to do the Collator checking, it will have to get
its hand on locale in it's boot method by going through code similar to
BasicDatabase.boot (copied above). This seems fine to me because then
everything related to boot is in boot method of the DVF and it does not have to
wait for DVF.setLocale to get it's locale set correctly. If we do decide to go
this path, then we can remove DVF.setLocal from BasicDatabase.boot and do the
locale setting in the DVF boot method.
Database creation and boot should fail if collation=TERRITORY_BASED and the
selected locale is not supported
Key: DERBY-3320
URL: https://issues.apache.org/jira/browse/DERBY-3320
Project: Derby
Issue Type: Bug
Affects Versions: 10.4.0.0
Environment: Java ME:
Product: phoneME Advanced (phoneme_advanced_mr2-b34)
Profile: Foundation Profile Specification 1.1
Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386
GNU/Linux
Reporter: Vemund Østgaard
Assignee: Mamta A. Satoor
Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt,
DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java
A problem I've discovered when testing with the phoneME advanced platform is
that the collationtests expect other locales than Locale.US to be available
on the platform that is used for the test, and for phoneME advanced (when
compiled as foundation profile) only Locale.US is available. From the jdk1.6
javadoc of Collator.getAvailableLocales() I see that only Locale.US is
strictly required:
public static Locale[] getAvailableLocales()
Returns an array of all locales for which the getInstance methods of this
class can return localized instances. The returned array represents the union
of locales supported by the Java runtime and by installed CollatorProvider
implementations. It must contain at least a Locale instance equal to
Locale.US.
Returns:
An array of locales for which localized Collator instances are
available.
This led me to thinking about how Derby should behave if created/booted with
collation=TERRITORY_BASED and territory=some unsupported locale. I'm not
sure what the consequences could be if the database is first created on a
platform that supports whatever locale is set and later booted with one that
doesn't, or created on a platform missing support and later booted with one
that has. In any case I think it may confuse a user needlessly to see the
database boot successfully with his collation setting and later behave in a
way he does not expect.
Opinions voiced on the derby-dev list are that both database creation and
boot should fail if collation=TERRITORY_BASED and the selected locale is not
supported.
If a change like this is implemented, the collationtests should be changed to
verify correct behavior also if they are executed in an environment were some
of the tested locales are not supported.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3555) Hang forever while trying to run ant junitreport
Hang forever while trying to run ant junitreport -- Key: DERBY-3555 URL: https://issues.apache.org/jira/browse/DERBY-3555 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.5.0.0 Environment: sane classes built off of trunk on a windows XP machine with 4 processors, running ibm16 jvm. java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr1-20080309_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080308 _17822 (JIT enabled, AOT enabled) J9VM - 20080308_017822_lHdSMr JIT - r9_20080307_1821 GC - 20080305_AB) JCL - 20080301_01 Reporter: Mike Matrigali Running ant junit report has consistently hung forever in this configuration (I think I have tried about 4 times on various latest builds off of the trunk. The latest try was against build 638425. I will attach a zip of the junit report information. On windows I could only get the stack trace from the ant control jvm, not sure how to get the actual test jvm to dump javacore to see what is going on there. I have been able to consistently run ant junitreport against the trunk and ibm15 jvm, this is the first time on this machine I have tried running the tests this way against ibm16. I will also try going back to the direct runner separate from ant to see if maybe the hang is ant related. In the old harness I have seen timing issues with the control and child jvm getting out of sync. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3555) Hang forever while trying to run ant junitreport
[ https://issues.apache.org/jira/browse/DERBY-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3555: -- Attachment: junit_20080319_.zip Hang forever while trying to run ant junitreport -- Key: DERBY-3555 URL: https://issues.apache.org/jira/browse/DERBY-3555 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.5.0.0 Environment: sane classes built off of trunk on a windows XP machine with 4 processors, running ibm16 jvm. java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr1-20080309_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080308 _17822 (JIT enabled, AOT enabled) J9VM - 20080308_017822_lHdSMr JIT - r9_20080307_1821 GC - 20080305_AB) JCL - 20080301_01 Reporter: Mike Matrigali Attachments: junit_20080319_.zip Running ant junit report has consistently hung forever in this configuration (I think I have tried about 4 times on various latest builds off of the trunk. The latest try was against build 638425. I will attach a zip of the junit report information. On windows I could only get the stack trace from the ant control jvm, not sure how to get the actual test jvm to dump javacore to see what is going on there. I have been able to consistently run ant junitreport against the trunk and ibm15 jvm, this is the first time on this machine I have tried running the tests this way against ibm16. I will also try going back to the direct runner separate from ant to see if maybe the hang is ant related. In the old harness I have seen timing issues with the control and child jvm getting out of sync. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3555) Hang forever while trying to run ant junitreport
[ https://issues.apache.org/jira/browse/DERBY-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580503#action_12580503 ] Daniel John Debrunner commented on DERBY-3555: -- Possibly due to DERBY-3544?? Hang forever while trying to run ant junitreport -- Key: DERBY-3555 URL: https://issues.apache.org/jira/browse/DERBY-3555 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.5.0.0 Environment: sane classes built off of trunk on a windows XP machine with 4 processors, running ibm16 jvm. java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr1-20080309_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080308 _17822 (JIT enabled, AOT enabled) J9VM - 20080308_017822_lHdSMr JIT - r9_20080307_1821 GC - 20080305_AB) JCL - 20080301_01 Reporter: Mike Matrigali Attachments: junit_20080319_.zip Running ant junit report has consistently hung forever in this configuration (I think I have tried about 4 times on various latest builds off of the trunk. The latest try was against build 638425. I will attach a zip of the junit report information. On windows I could only get the stack trace from the ant control jvm, not sure how to get the actual test jvm to dump javacore to see what is going on there. I have been able to consistently run ant junitreport against the trunk and ibm15 jvm, this is the first time on this machine I have tried running the tests this way against ibm16. I will also try going back to the direct runner separate from ant to see if maybe the hang is ant related. In the old harness I have seen timing issues with the control and child jvm getting out of sync. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3555) Hang forever while trying to run ant junitreport
[ https://issues.apache.org/jira/browse/DERBY-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3555: -- not sure if it is useful but here is the dump from ant jvm side while it was hanging: Searching for build.xml ... Buildfile: F:\p4\m1\build.xml junit-init: [mkdir] Created dir: F:\p4\m1\opensource\junit_20080319_\testout junit-core: [junit] Running org.apache.derbyTesting.junit.EnvTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.297 sec [junit] Running org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.89 sec [junit] Running org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversEmbeddedTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 6.015 sec [junit] Running org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversClientTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.938 sec [junit] Running org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversAllTest [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 14.594 sec [junit] Running org.apache.derbyTesting.functionTests.tests.derbynet._Suite [junit] Tests run: 76, Failures: 0, Errors: 0, Time elapsed: 100.687 sec [junit] Running org.apache.derbyTesting.functionTests.tests.tools._Suite [junit] Tests run: 80, Failures: 0, Errors: 0, Time elapsed: 96.469 sec [junit] Running org.apache.derbyTesting.functionTests.tests.demo._Suite [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 34.469 sec [junit] Running org.apache.derbyTesting.functionTests.tests.lang._Suite Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-b05 mixed mode): Thread-19 daemon prio=6 tid=0x0b058748 nid=0xa18 runnable [0x0b2cf000..0x0b2cfbe8] at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:177) at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:90) at java.lang.Thread.run(Thread.java:595) Thread-18 daemon prio=6 tid=0x0b036708 nid=0xf50 runnable [0x0b28f000..0x0b28fc68] at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:194) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) - locked 0x02b03710 (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:90) at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:90) at java.lang.Thread.run(Thread.java:595) Low Memory Detector daemon prio=6 tid=0x00a98d20 nid=0xf54 runnable [0x..0x] CompilerThread0 daemon prio=10 tid=0x00a97a50 nid=0x804 waiting on condition [0x..0x0abcf848] Signal Dispatcher daemon prio=10 tid=0x00a96df0 nid=0x4f8 waiting on condition [0x..0x] Finalizer daemon prio=8 tid=0x00a8dfc8 nid=0xcbc in Object.wait() [0x0ab4f000..0x0ab4fc68] at java.lang.Object.wait(Native Method) - waiting on 0x02fc81f8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked 0x02fc81f8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=10 tid=0x00a8cb58 nid=0x698 in Object.wait() [0x0ab0f000..0x0ab0fce8] at java.lang.Object.wait(Native Method) - waiting on 0x02fc8278 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0x02fc8278 (a java.lang.ref.Reference$Lock) main prio=6 tid=0x0003a7d0 nid=0xee4 runnable [0x0007f000..0x0007fc3c] at java.lang.ProcessImpl.waitFor(Native Method) at org.apache.tools.ant.taskdefs.Execute.waitFor(Execute.java:539) at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:471) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:880) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:685) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1434) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:632) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at
[jira] Updated: (DERBY-3544) If NetworkServer fails to shutdown, test run will hang
[ https://issues.apache.org/jira/browse/DERBY-3544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner updated DERBY-3544: - Attachment: derby3544_diff.txt Patch that destroys the server process if the shutdown command failed. If NetworkServer fails to shutdown, test run will hang -- Key: DERBY-3544 URL: https://issues.apache.org/jira/browse/DERBY-3544 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.2.2, 10.4.1.0, 10.5.0.0 Reporter: Kathey Marsden Attachments: derby3544_diff.txt If the NetworkServer fails to shutdown for some reason, we do not clean up the process but will just hang the tests. We should kill off the process if the server fails to shutdown and continue. To reproduce try runnning the test derbynet.SecureServerTest with 10.3 derbyTesting.jar and 10.4 jars. See DERBY-3534 for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (DERBY-3169) Add documentation for replication
Kim Haase wrote: Thanks for the info, Dan -- I will study it. Rick Hillegas had asked me for some information so he could set up an apache.org account for me (I guess this would be separate from my JIRA login), so I've been waiting to hear back on that before I went any further. Yes, you do need an Apache account, (and it is different form your Jira account), before you can commit fixes. I would suggest taking some time to familiarize yourself with your Apache account, creating and uploading keys, and so on. At least I had to that... :) Dyre
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580510#action_12580510 ] Daniel John Debrunner commented on DERBY-2109: -- Just to add I think the current commit changes fix two bugs: 1) If a network server shutdown also shuts down the database engine and authentication is enabled then previously the database shutdown would fail. E.g. a clean shutdown would not occur and recovery would be needed. 2) Any user on the same machine could shutdown any network server even if they did not posses any valid authentication credentials. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, DERBY-2109-12.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: beta build version
Kathey Marsden wrote: I noticed the beta build version has an 'M' [C:\testcompat\jars\derby.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbytools.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbynet.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbyclient.jar] 10.4.1.0 beta - (637204M) -- not a big deal for beta, but for the release, it would be good to make sure all changes are checked in before the build. Yes, I read this in the instructions for creating a release. I do think that the 'M' is there because I did not commit the changes I had made to releaseSummary.xml. I didn't want to do that because I felt it was rather unfinished (see the mail I sent about the feature descriptions). On a related note: Should releaseSummary.xml be committed to trunk, and then merged to 10.4? In a way this seems unnecessary, since its content will only ever be needed on a specific branch, but the 10.3 content is currently found on trunk, so I guess it has been committed to trunk in the past... Also: The release instructions seem to suggest that the CHANGES file was deprecated in 10.3, and that I shouldn't try to create it for 10.4. Is that understanding correct? Dyre
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580514#action_12580514 ] Dyre Tjeldvoll commented on DERBY-3301: --- The following Wiki page http://wiki.apache.org/db-derby/ReleaseNoteProcess has some info about how to format releaseNote.html Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580515#action_12580515 ] Rick Hillegas commented on DERBY-2109: -- Thanks to Martin and Dan for the crisp summary of the existing compatibility issues. I think that that we have fixed a very serious security problem. We should keep this more secure behavior in the 10.4 release even though, as Kathey points out, the extra security will cause extra pain. I think this is pretty much how the industry responds to serious security breaches today. The trend is to push security patches to the field as soon as the patches are available and not defer them for a half year. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, DERBY-2109-12.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: beta build version
Dyre Tjeldvoll wrote: Kathey Marsden wrote: I noticed the beta build version has an 'M' [C:\testcompat\jars\derby.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbytools.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbynet.jar] 10.4.1.0 beta - (637204M) [C:\testcompat\jars\derbyclient.jar] 10.4.1.0 beta - (637204M) -- not a big deal for beta, but for the release, it would be good to make sure all changes are checked in before the build. Yes, I read this in the instructions for creating a release. I do think that the 'M' is there because I did not commit the changes I had made to releaseSummary.xml. I didn't want to do that because I felt it was rather unfinished (see the mail I sent about the feature descriptions). On a related note: Should releaseSummary.xml be committed to trunk, and then merged to 10.4? In a way this seems unnecessary, since its content will only ever be needed on a specific branch, but the 10.3 content is currently found on trunk, so I guess it has been committed to trunk in the past... Hi Dyre, I don't see any reason to commit releaseSummary.xml to the trunk. Also: The release instructions seem to suggest that the CHANGES file was deprecated in 10.3, and that I shouldn't try to create it for 10.4. Is that understanding correct? The release instructions certainly treat CHANGES as a deprecated file. Maybe Myrna or Kathey can shed some light on this issue. Regards, -Rick Dyre
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580520#action_12580520 ] Daniel John Debrunner commented on DERBY-2109: -- What I should have said was the current commit *attempts to* fix two bugs: Given DERBY-3543 and DERBY-3537 (which may be the same issue) I'm not convinced that it does fix this: 2) Any user on the same machine could shutdown any network server even if they did not posses any valid authentication credentials. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, DERBY-2109-12.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- 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-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580520#action_12580520 ] djd edited comment on DERBY-2109 at 3/19/08 1:05 PM: --- What I should have said was the current commit *attempts to* fix two bugs: Given DERBY-3537 and the behaviour seen in [1] I'm not convinced that it does fix this: 2) Any user on the same machine could shutdown any network server even if they did not posses any valid authentication credentials. [1] https://issues.apache.org/jira/browse/DERBY-3534?focusedCommentId=12578892#action_12578892 [edit to refer to correct problem] was (Author: djd): What I should have said was the current commit *attempts to* fix two bugs: Given DERBY-3543 and DERBY-3537 (which may be the same issue) I'm not convinced that it does fix this: 2) Any user on the same machine could shutdown any network server even if they did not posses any valid authentication credentials. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, DERBY-2109-12.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3545) NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation
[ https://issues.apache.org/jira/browse/DERBY-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580532#action_12580532 ] Rick Hillegas commented on DERBY-3545: -- I'm afraid I still cannot reproduce this problem. Using Java 5 on Mac OS X with both sane and insane jar files, I do not see this problem when I run the following ant command ant junit-clean junit-all-codeline-jars I do, however, see the following problem in the jdbcapi suite using both sane and insane jars: testcase classname=org.apache.derbyTesting.functionTests.tests.jdbcapi.SetTransactionIsolationTest$1 name=unknown time=0.0 error message=Limitation: Record 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. type=org.apache.derby.impl.jdbc.EmbedSQLExceptionjava.sql.SQLException: Limitation: Record 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.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:201) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2082) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1325) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652) at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(EmbedCallableStatement.java:117) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1307) at org.apache.derbyTesting.junit.CleanDatabaseTestSetup.compressObjects(CleanDatabaseTestSetup.java:267) at org.apache.derbyTesting.junit.CleanDatabaseTestSetup.cleanDatabase(CleanDatabaseTestSetup.java:166) at org.apache.derbyTesting.junit.CleanDatabaseTestSetup.setUp(CleanDatabaseTestSetup.java:109) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: ERROR XSDA3: Limitation: Record 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.raw.data.CopyRowsOperation.writeOptionalDataToBuffer(CopyRowsOperation.java:287) at org.apache.derby.impl.store.raw.data.CopyRowsOperation.lt;initgt;(CopyRowsOperation.java:98) at org.apache.derby.impl.store.raw.data.LoggableActions.actionCopyRows(LoggableActions.java:159) at org.apache.derby.impl.store.raw.data.BasePage.copyInto(BasePage.java:2045) at org.apache.derby.impl.store.raw.data.BasePage.copyAndPurge(BasePage.java:1300) at org.apache.derby.impl.store.raw.data.StoredPage.moveRecordForCompressAtSlot(StoredPage.java:6920) at org.apache.derby.impl.store.access.heap.HeapCompressScan.fetchRowsForCompress(HeapCompressScan.java:230) at org.apache.derby.impl.store.access.heap.HeapCompressScan.fetchNextGroup(HeapCompressScan.java:85) at org.apache.derby.iapi.db.OnlineCompress.defragmentRows(OnlineCompress.java:375) at org.apache.derby.iapi.db.OnlineCompress.compressTable(OnlineCompress.java:219) at org.apache.derby.catalog.SystemProcedures.SYSCS_INPLACE_COMPRESS_TABLE(SystemProcedures.java:942) at org.apache.derby.exe.ac8c8908bex0118xc7c0x9cecx8cd227a82.g0(Unknown Source) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(CallStatementResultSet.java:90) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:372) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235) /error /testcase NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation - Key: DERBY-3545 URL:
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580533#action_12580533 ] Kathey Marsden commented on DERBY-2109: --- The issue reported with: https://issues.apache.org/jira/browse/DERBY-3534?focusedCommentId=12578892#action_12578892 where I thought the server was not coming down was user error. The test was bringing the server back up quickly and I thought it wasn't going down. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, DERBY-2109-12.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3543) NetworkServerControl with user password but no command does not give usage message
[ https://issues.apache.org/jira/browse/DERBY-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580538#action_12580538 ] Martin Zaun commented on DERBY-3543: The same issue is also shown with other command line options, for example: java org.apache.derby.drda.NetworkServerControl -noSecurityManager returns with no usage message too. However that's not for all options, for instance, java org.apache.derby.drda.NetworkServerControl -host localhost does return with an error message. Seems to be a broader issue with the command/option parsing code in NetworkServerControlImpl. I keep staring at it for a little more time to see if there's an obvious error and a fix. NetworkServerControl with user password but no command does not give usage message -- Key: DERBY-3543 URL: https://issues.apache.org/jira/browse/DERBY-3543 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.4.1.0, 10.5.0.0 Reporter: Kathey Marsden Priority: Minor I noticed that java org.apache.derby.drda.NetworkServerControl -user mary -password mypass with no actual command just completes with no usage message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3543) NetworkServerControl with user password but no command does not give usage message
[ https://issues.apache.org/jira/browse/DERBY-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580541#action_12580541 ] Martin Zaun commented on DERBY-3543: However that's not for all options, for instance, java org.apache.derby.drda.NetworkServerControl -host localhost does return with an error message. Well, this is because, there is no -host option. However that's not for all options, for instance, java org.apache.derby.drda.NetworkServerControl -h localhost also does NOT print an error message. NetworkServerControl with user password but no command does not give usage message -- Key: DERBY-3543 URL: https://issues.apache.org/jira/browse/DERBY-3543 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.4.1.0, 10.5.0.0 Reporter: Kathey Marsden Priority: Minor I noticed that java org.apache.derby.drda.NetworkServerControl -user mary -password mypass with no actual command just completes with no usage message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-3555) Hang forever while trying to run ant junitreport
Daniel John Debrunner (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580503#action_12580503 ] Daniel John Debrunner commented on DERBY-3555: -- Possibly due to DERBY-3544?? I will try out the DERBY-3544 patch and post whether it helps or not. Hang forever while trying to run ant junitreport -- Key: DERBY-3555 URL: https://issues.apache.org/jira/browse/DERBY-3555 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.5.0.0 Environment: sane classes built off of trunk on a windows XP machine with 4 processors, running ibm16 jvm. java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr1-20080309_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080308 _17822 (JIT enabled, AOT enabled) J9VM - 20080308_017822_lHdSMr JIT - r9_20080307_1821 GC - 20080305_AB) JCL - 20080301_01 Reporter: Mike Matrigali Attachments: junit_20080319_.zip Running ant junit report has consistently hung forever in this configuration (I think I have tried about 4 times on various latest builds off of the trunk. The latest try was against build 638425. I will attach a zip of the junit report information. On windows I could only get the stack trace from the ant control jvm, not sure how to get the actual test jvm to dump javacore to see what is going on there. I have been able to consistently run ant junitreport against the trunk and ibm15 jvm, this is the first time on this machine I have tried running the tests this way against ibm16. I will also try going back to the direct runner separate from ant to see if maybe the hang is ant related. In the old harness I have seen timing issues with the control and child jvm getting out of sync.
[jira] Commented: (DERBY-3536) specialCollation() and noSpecialCollation() in TableFunctionTest fail with weme6.1.
[ https://issues.apache.org/jira/browse/DERBY-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580548#action_12580548 ] Rick Hillegas commented on DERBY-3536: -- Thanks, Mike. That sounds like a separate issue. Maybe we can get some advice from someone who understands the Java security behavior on that platform. specialCollation() and noSpecialCollation() in TableFunctionTest fail with weme6.1. --- Key: DERBY-3536 URL: https://issues.apache.org/jira/browse/DERBY-3536 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: A B Priority: Minor Attachments: derby-3536-01-aa-decimalCast.diff The specialCollation() and noSpecialCollation() fixtures in TableFunctionTest fail when run with weme6.1. I have not explicitly confirmed but it looks like this may be related to svn # 636004. The stack trace is: noSpecialCollation(o.a.dTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at o.a.d.impl.jdbc.Util.generateCsSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedConnection.handleException(Unknown Source) at o.a.d.impl.jdbc.ConnectionChild.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.next(Unknown Source) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.allLegalDatatypesVTIResults(TableFunctionTest.java:1178) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:921) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at o.a.dTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) Caused by: ERROR 22005: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.iapi.error.StandardException.newException(Unknown Source) at o.a.d.iapi.types.DataType.dataTypeConversion(Unknown Source) at o.a.d.iapi.types.DataType.getObject(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.cast(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at o.a.d.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) Comments from RIck on derby-dev (in response to DERBY-3341 inquiry): The handling of DECIMAL on the small device platform is different. The test may need some special logic so that it calls the correct method for the small device environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: beta build version
On 3/19/08, Rick Hillegas [EMAIL PROTECTED] wrote: Also: The release instructions seem to suggest that the CHANGES file was deprecated in 10.3, and that I shouldn't try to create it for 10.4. Is that understanding correct? The release instructions certainly treat CHANGES as a deprecated file. Maybe Myrna or Kathey can shed some light on this issue. Regards, -Rick Dyre During the initial 10.3 process I looked at what was in the 10.2 'CHANGES' file (note: not 'CHANGES.html') and it was fairly identical to what was in the release notes. There was a discussion about it and I think I concluded 'RELEASE-NOTES.html' was enough. I think part of this discussion is maybe in this thread: http://www.nabble.com/Release-Notes-to5931299.html However, subsequently, there was discussion to the effect that we should not have all changes in the Release Notes, instead, we should only have those affecting (end-)users. Thus the 'CHANGES.html' file was born, listing (also, I think) changes not visible to end-users. Part of the discussion can be followed in this thread: http://www.nabble.com/10.3-Release-Notes-to11502532.html#a11502532 In my edits of the wiki I left a reference to 'CHANGES' - not 'CHANGES.html' - for the possibility we'd pull another release off the 10.2 branch. I agree the name is confusing. But what better name for a file to list the changes? It's unlikely now that we'll pull another release off 10.2, probably better to remove reference to the 10.2 'CHANGES' file and only mention 'CHANGES.html'. HTH... Myrna
[jira] Commented: (DERBY-3536) specialCollation() and noSpecialCollation() in TableFunctionTest fail with weme6.1.
[ https://issues.apache.org/jira/browse/DERBY-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580549#action_12580549 ] Daniel John Debrunner commented on DERBY-3536: -- Are you running the tests with WEME 6.1 as required? http://wiki.apache.org/db-derby/JunitVmIssues#head-660f05752b5de460a55db1f7ff67ce869af2d38e specialCollation() and noSpecialCollation() in TableFunctionTest fail with weme6.1. --- Key: DERBY-3536 URL: https://issues.apache.org/jira/browse/DERBY-3536 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: A B Priority: Minor Attachments: derby-3536-01-aa-decimalCast.diff The specialCollation() and noSpecialCollation() fixtures in TableFunctionTest fail when run with weme6.1. I have not explicitly confirmed but it looks like this may be related to svn # 636004. The stack trace is: noSpecialCollation(o.a.dTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at o.a.d.impl.jdbc.Util.generateCsSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedConnection.handleException(Unknown Source) at o.a.d.impl.jdbc.ConnectionChild.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.next(Unknown Source) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.allLegalDatatypesVTIResults(TableFunctionTest.java:1178) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:921) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at o.a.dTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) Caused by: ERROR 22005: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.iapi.error.StandardException.newException(Unknown Source) at o.a.d.iapi.types.DataType.dataTypeConversion(Unknown Source) at o.a.d.iapi.types.DataType.getObject(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.cast(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at o.a.d.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) Comments from RIck on derby-dev (in response to DERBY-3341 inquiry): The handling of DECIMAL on the small device platform is different. The test may need some special logic so that it calls the correct method for the small device environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3556) change derby.tests.trace property to print the name of the test before it runs it
change derby.tests.trace property to print the name of the test before it runs it - Key: DERBY-3556 URL: https://issues.apache.org/jira/browse/DERBY-3556 Project: Derby Issue Type: Improvement Components: Newcomer, Test Affects Versions: 10.5.0.0 Reporter: Kathey Marsden Priority: Trivial If a test hangs for some reason it is useful to know what test is running when the hang occurs. It would therefore be good if the derby.tests.trace property printed the test name before it ran the test instead of after. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3373) SQL distinct and order by needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580557#action_12580557 ] Bryan Pendleton commented on DERBY-3373: Merged the trunk change to the 10.4 branch and committed as revision 639013. SQL distinct and order by needed together - Key: DERBY-3373 URL: https://issues.apache.org/jira/browse/DERBY-3373 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.2.1 Environment: Solaris Dev Express, Java 5 Reporter: Thomas Vatter Assignee: Bryan Pendleton Priority: Blocker Fix For: 10.3.2.2, 10.4.0.0 Attachments: allowExpressions.diff, mergeWith2351.diff I am pasting here the communication from the mailinglist. I am having a blocking and large problem with it because I have to make a release that needs the specified SQL query. tom_ wrote: The errormessage is The ORDER BY clause may not specify an expression, since the query specifies DISTINCT [Error Code: 2] [SQL State: 4287A] The statement is select distinct t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 from t1, t2, t3 where ... order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) Dyre.Tjeldvoll wrote: tom_ [EMAIL PROTECTED] writes: I am using disctinct because of some self-joins and also needed to add an order by clause. An error is shown. Is it not possible to use distinct and order by together? I think it is allowed. Executing select distinct * from sys.systables order by tablename; in ij works just fine. Could you show the error message you get, and perhaps what the table looks like? -- dt « [hide part of quote] Hi Tom - I see what you mean using the demo DB toursDB: ij select * from airlines order by lower(airline_full); A|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT |BUSINESS_LEVEL_FACTOR |FIRSTCLASS_LEVEL_FACT|ECONOMY_SE|BUSINESS_S|FIRSTCLASS --- AA|Amazonian Airways |0.18 |0.03 |0.5 |1.5 |20 |10 |5 US|Union Standard Airlines |0.19 |0.05 |0.4 |1.6 |20 |10 |5 2 rows selected ij select distinct * from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij select distinct airline_full from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij I didn't find a JIRA enhancement to remove this restriction. I suggest you file an Enhancement request to remove the restriction reported by ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3557) hang in derbyall/storeall/storemore/OnlineCompressTest after java.lang.IllegalMonitorStateException with ibm 1.6
hang in derbyall/storeall/storemore/OnlineCompressTest after java.lang.IllegalMonitorStateException with ibm 1.6 Key: DERBY-3557 URL: https://issues.apache.org/jira/browse/DERBY-3557 Project: Derby Issue Type: Bug Components: Regression Test Failure Environment: Java Version:1.6.0 Java Vendor: IBM Corporation Classpath: all derby*.jars, junit.jar, jakarta-oro-2.0.8.jar OS name: Linux OS architecture: x86 OS version: 2.6.5-7.283-bigsmp java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.5.0.0 alpha - (638673) etc. java -version: java version 1.6.0 Java(TM) SE Runtime Environment (build pxi3260sr1-20080307_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20080305_1775 5 (JIT enabled, AOT enabled) J9VM - 20080305_017755_lHdSMr JIT - r9_20080304_1821 GC - 20080305_AB) JCL - 20080301_01 Reporter: Myrna van Lunteren Hang on linux in derbyall/storeall/storemore/store/OnlineCompressTest.java with ibm16. The diff is as follows: Executing test: delete all rows case succeeded. Executing test: end simple deleteAllRows,104000 row test. Ending test: test6 Beginning test: test7 Executing test: delete rows case succeeded. Ending test: test7 suggesting that we didn't get through the 'delete all rows case' of 'test6'. derby.log shows some expected: ERROR 40XL1: A lock could not be obtained within the time requested, followed by: - java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:127) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1175) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431) at org.apache.derby.impl.services.locks.ConcurrentLockSet$Entry.unlock(Unknown Source) at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown Source) at org.apache.derby.impl.services.locks.AbstractPool.lockObject(UnknownSource) at org.apache.derby.impl.store.raw.xact.RowLocking3.lockContainer(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source) at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(Unknown Source) at org.apache.derby.impl.store.access.heap.Heap.open(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapPostCommit.performWork(Unknown Source) at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown Source) at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown Source) at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) at java.lang.Thread.run(Thread.java:735) -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated DERBY-3301: - Attachment: Derby-3301.html I've tried to summarize the issue with the attached release note. Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, Derby-3301.html, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE |WEEKLYHOURS
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580576#action_12580576 ] Daniel John Debrunner commented on DERBY-3301: -- I think the release note has its sections or tenses mixed up: Applications that execute SQL statements containing nested EXISTS clauses can see fewer rows than satisfy the query. Hopefully Derby returns the correct results, not fewer rows than the query is meant to return. Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, Derby-3301.html, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580578#action_12580578 ] Kathey Marsden commented on DERBY-3301: --- I think also the file needs to be called releaseNote.html for it to work with the release note generator. Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, Derby-3301.html, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY
[jira] Updated: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated DERBY-3301: - Attachment: releaseNote.html I've changed the description to address the tense issue, and changed the name of the file. Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, Derby-3301.html, derby-3301.sql, releaseNote.html Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580586#action_12580586 ] Daniel John Debrunner commented on DERBY-3301: -- Looks better, I think the Summary of the Change section is incorrect: Derby can return fewer rows than expected. That describes the old bug not a change, well it doesn't really describe anything since it's so vague. :-) Is the summary more along the lines of: Queries with nested EXIST clauses now return correct results. ??? Maybe someone more familiar with the issue could come up with the correct wording? I'm not really sure that such changes require release notes, looking at this: Applications that depended on the previous incorrect behavior will need to be updated. what does that really mean? How would such an application be updated? Maybe a release note is good, but not suggesting application changes. More along the lines of: Applications using nested EXISTS may have previously returned incorrect results. which is what the Symptoms section is for (and says) so maybe these two sections are not required for wrong result fixes: Incompatibilities with Previous Release Application Changes Required To reduce to a simple case, if the expression x + 2 actually returned x + 3 for any x, then would it make sense to have a release note that effectively said applications that depended on the incorrect addition of 2 need to be updated?? Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, Derby-3301.html, derby-3301.sql, releaseNote.html Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT
[jira] Updated: (DERBY-3543) NetworkServerControl with user password but no command does not give usage message
[
https://issues.apache.org/jira/browse/DERBY-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Zaun updated DERBY-3543:
---
Attachment: DERBY-3542-0_experimental.diff
DERBY-3542-0_experimental.stat
Having had a closer look into this issue, I'm attaching an experimental patch
for comments (I quickly tested the patch but did not run any test suites).
As stated above, this issue is unrelated to DERBY-2109: The usage text is not
printed if any command-line argument has been given, even if a command is still
missing.
For instance:
java org.apache.derby.drda.NetworkServerControl
prints the usage text while
java org.apache.derby.drda.NetworkServerControl -h localhost
does not.
The patch results changes the behaviour to that a usage message is always
printed when no command has been given, regardless of whether any options have
been specified.
There are a number of finepoints described below.
--
First, there is a swallowed exception, I'd call it a bug, in method
NetworkServerControlImpl.findCommand(String[]), around line 2145:
// didn't find command
consolePropertyMessage(DRDA_UnknownCommand.U,
(String) commandArgs.firstElement());
a) When no actual command was given, the Vector commandArgs is still empty.
b) It then happens that commandArgs.firstElement() throws a
NoSuchElementException.
c) Unfortunately, this exception is swallowed by the following catch clause:
} catch (Exception e) {
if
(e.getMessage().equals(NetworkServerControlImpl.UNEXPECTED_ERR))
throw e;
//Ignore expected exceptions, they will have been
//handled by the consolePropertyMessage routine
}
A fix is very simple: move a closing brace } a few lines down, so that the
block structure becomes:
if (commandArgs.size() 0)
{
...
// didn't find command
consolePropertyMessage(DRDA_UnknownCommand.U,
(String) commandArgs.firstElement());
}
When no actual command was given, the block is not executed.
The method findCommand(String[]) ends with:
return COMMAND_UNKNOWN;
--
Second, and more importantly, the method
NetworkServerControlImpl.parseArgs(String[]) shows some twisted logic:
int command = COMMAND_START;
if (args.length 0)
command = findCommand(args);
else
{
consolePropertyMessage(DRDA_NoArgs.U);
}
return command;
a) It assigns a default command (start).
b) However, if no command (or option) it calls
consolePropertyMessage(DRDA_NoArgs.U);
which prints a usage message and EXITS -- as I've found out to my surprise.
I didn't expect a method named consolePropertyMessage() to have such dramatic
side-effects.
c) The usage message clearly indicates that there's no default command:
Usage: NetworkServerControl commands
Commands:
start [-h host] [-p portnumber] [-noSecurityManager] [-ssl sslmode]
shutdown [-h host][-p portnumber] [-ssl sslmode] [-user username] [-pass
word password]
ping [-h host][-p portnumber] [-ssl sslmode]
sysinfo [-h host][-p portnumber] [-ssl sslmode]
runtimeinfo [-h host][-p portnumber] [-ssl sslmode]
logconnections {on|off}[-h host][-p portnumber] [-ssl sslmode]
maxthreads max[-h host][-p portnumber] [-ssl sslmode]
timeslice milliseconds[-h host][-p portnumber] [-ssl sslmode]
trace {on|off} [-s session id][-h host][-p portnumber] [-ssl sslmode]
tracedirectory traceDirectory[-h host][-p portnumber] [-ssl sslmode]
d) If, however, any command-line argument was given and findCommand() runs into
any problems it returns COMMAND_UNKNOWN, in which case the assigned default
command has got overridden.
To summarize: Perhaps, there once was such a thing as a default command
(start) in the past, but points b), c), and d) indicate to me that this has
not been supported for a while.
So, under the assumption that users MUST provide a command to
NetworkServerControl and if they have not done so that
- a usage message is to be printed regardless of whether additional options
were provided or not and
- NetworkServerControl should then exit
the method parseArgs(String[]) can be nicely cleaned up and implemented as:
int command = findCommand(args);
if (command == COMMAND_UNKNOWN)
{
consolePropertyMessage(DRDA_NoArgs.U);
}
return
[jira] Commented: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment
[ https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580598#action_12580598 ] Stan Bradbury commented on DERBY-3513: -- Kathey - Please DO commit this change to the 10.1 codeline afterall. The customer experiencing the failure has continued to test with your patch (in 11 builds to date) and has only observed the NPE failure once (on 3/12/08). The failure rate prior to this change was 35% (a failure approximately every 3 builds). Your patch, if not correcting the problem, has at least greatly reduced the frequency with which it happens. I will post to this issue should another build encounter the NPE problem. If there are no further occurrences I think it is safe to say that the failure reported on 3/12 was an anomaly. NullPointerException in newBrokeredStatement in app server environment -- Key: DERBY-3513 URL: https://issues.apache.org/jira/browse/DERBY-3513 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.3.2 Environment: Java Version:1.5.0 Java Vendor: IBM Corporation OS name: Linux OS architecture: x86 OS version: 2.6.9-55.ELsmp Reporter: Kathey Marsden Assignee: Kathey Marsden Attachments: derby-3513_diff.txt User reports in an app server environment an intermittent NullPointerException with the 10.1 trace: R java.lang.NullPointerException org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448) ...org.apache.derby.jdbc.XAStatementControl.init(XAStatementControl.java:62) ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827) org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296) [snip user trace] The code at line 448 is simply: return new BrokeredStatement(statementControl, getJDBCLevel()); so not much room for an NPE there. I added println statements to identify the state values and where the NPE is actually occurring but that seemed to make the problem go away. It may be a JIT issue. I gave them the fix for DERBY-2142 and that did not correct the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3548) NoClassDefFoundError failure in SystemPrivilegesPermissionTest for weme6.1
[ https://issues.apache.org/jira/browse/DERBY-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner reassigned DERBY-3548: Assignee: Daniel John Debrunner NoClassDefFoundError failure in SystemPrivilegesPermissionTest for weme6.1 -- Key: DERBY-3548 URL: https://issues.apache.org/jira/browse/DERBY-3548 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.5.0.0 Reporter: A B Assignee: Daniel John Debrunner Priority: Minor SystemPrivilegesPermissionTest.testSystemPermission failed on weme6.1 at svn # 636947 with a NoClassDefFoundError: testSystemPermission(org.apache.derbyTesting.unitTests.junit.SystemPrivilegesPermissionTest) java.lang.NoClassDefFoundError: javax.security.auth.Subject at ...SystemPrivilegesPermissionTest$RunAsPrivilegedUserAction.run(SystemPrivilegesPermissionTest.java:737) at java.security.AccessController.doPrivileged(AccessController.java:191) at ...SystemPrivilegesPermissionTest.execute(SystemPrivilegesPermissionTest.java:531) at ...SystemPrivilegesPermissionTest.testSystemPermission(SystemPrivilegesPermissionTest.java:318) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) 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) The following lines showed up in sysout or syserr a total of 3 times: Parsing policy file: jar:file:[...]classes/derbyTesting.jar!/org/apache/derbyTesting/unitTests/junit/SystemPrivilegesPermissionTest.policy, found unexpected: principal I assume that's related, but do not know for sure... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment
[ https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580606#action_12580606 ] Kathey Marsden commented on DERBY-3513: --- OK then, I will go ahead and commit it, but I fear it will only make the problem more elusive and hard to reproduce. When they get to the point that they are able to run JIT diagnostics it might make sense to test with the earlier build where it is easier to reproduce. NullPointerException in newBrokeredStatement in app server environment -- Key: DERBY-3513 URL: https://issues.apache.org/jira/browse/DERBY-3513 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.3.2 Environment: Java Version:1.5.0 Java Vendor: IBM Corporation OS name: Linux OS architecture: x86 OS version: 2.6.9-55.ELsmp Reporter: Kathey Marsden Assignee: Kathey Marsden Attachments: derby-3513_diff.txt User reports in an app server environment an intermittent NullPointerException with the 10.1 trace: R java.lang.NullPointerException org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448) ...org.apache.derby.jdbc.XAStatementControl.init(XAStatementControl.java:62) ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827) org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296) [snip user trace] The code at line 448 is simply: return new BrokeredStatement(statementControl, getJDBCLevel()); so not much room for an NPE there. I added println statements to identify the state values and where the NPE is actually occurring but that seemed to make the problem go away. It may be a JIT issue. I gave them the fix for DERBY-2142 and that did not correct the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
