[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568462#action_12568462 ] Thomas Nielsen commented on DERBY-2998: --- These are indeed the issues I'm looking into now. The incorrect results are caused by the source column mapping being messed up. I'm aware of the assert from the where ... order by query, but haven't had a chance to look closely at it yet. It's related to DERBY-3310, but rather (again) column mapping being off is causing us to map either an SQLInteger into a SQLLongint column or the other way around. I've uploaded the patches mainly so others can have a look if they're interested. I'm not really looking for any specific feedback - but any feedback is still appreciated. Thanks for taking the time :) Add support for ROW_NUMBER() window function Key: DERBY-2998 URL: https://issues.apache.org/jira/browse/DERBY-2998 Project: Derby Issue Type: Sub-task Components: SQL Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Minor Attachments: d2998-10.diff, d2998-10.stat, d2998-11.diff, d2998-4.diff, d2998-4.stat, d2998-5.diff, d2998-5.stat, d2998-6.diff, d2998-6.stat, d2998-7.diff, d2998-7.stat, d2998-8.diff, d2998-8.stat, d2998-9-derby.log, d2998-9.diff, d2998-9.stat, d2998-doc-1.diff, d2998-doc-1.stat, d2998-test.diff, d2998-test.stat, d2998-test2.diff, d2998-test2.stat, d2998-test3.diff, d2998-test3.stat As part of implementing the overall OLAP Operations features of SQL (DERBY-581), implement the ROW_NUMBER() window function. More information about this feature is available at http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trouble getting jvm options to work with suites
Kathey Marsden wrote: I am trying to run the whole suite with jit forced on with IBM JDK 1.6. To do this I use the -Xjit:count=0 option, but I am having trouble getting it to work when I run a suite. If I run a single test jdbcapi.DatabaseMetaDataTest with the -Xjit:count=0, all works as expected and I see the failures for DERBY-3400, but if I run a suite, such as jdbcapi._Suite, I don't see any failures so I don't think the options are taking effect. Here are the two command lines: Works as expected: 4 tests fail: java -Xjit:count=0 -Dderby.tests.trace=true junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest All tests pass: java -Xjit:count=0 -Dderby.tests.trace=true junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite I don't think the tests fork a process or anything so I don't understand how I could be losing the -Xjit:count=0 option. Does anyone have any idea what might be going on? Hi Kathey, I have no idea, but have you verified that the failing tests are in fact run as part of the suite? This can of course easily be verified by using the graphical test runner, or by putting some printlns into the relevant tests. I notice there isn't much fancy stuff going on in the suite method of DatabaseMetaDataTest, but it would be good to confirm it anyway. regards, -- Kristian Kathey
Opinions please - some questions regarding replication
I have a few questions regarding replication that would be great
to hear the community's opinion on before the 10.4 branching. The
reason for bringing this up before code freeze is that these will
have impact on existing applications if changed later.
1. The master of a replicated database ships log records and
other information to the slave through a network socket. 8001
is currently default port for this communication. From
http://www.iana.org/assignments/port-numbers it seems that
this port is reserved for
vcom-tunnel8001/tcpVCOM Tunnel
vcom-tunnel8001/udpVCOM Tunnel
Should we change port, and maybe even register a port in IANA,
or is it fine as it is? I have no idea how long it will take
to register a port, but chances are it will be longer than the
time we have for 10.4 with the current plan. Another
alternative is to use a port from the range called dynamic
and/or private ports (49152 through 65535) BTW: I noticed
that 1527 is registered by Oracle, which may also be a
problem?
tlisrv 1527/tcporacle
tlisrv 1527/udporacle
Note that this is only a question of default port. The port
number may be set explicitly by the client starting
replication.
2. About a week ago, Dibyendu Majumdar raised a question about
why the replication modules are placed under services and not
store. Should replication be moved from
org.apache.derby.{iapi|impl}.services.replication to e.g.
org.apache.derby.{iapi|impl}.store.replication, or is it OK to keep
the current placement?
3. Should replication be shipped in a separate JAR file? Pros and
cons as I see it:
+ Remove 65KB (unjared) of class files from derby.jar
+ Possible to have a different security policy file for replication?
- Yet another JAR file
--
Jørgen Løland
[jira] Updated: (DERBY-2128) The wrod class appears twice for the message SIF01.V
[ https://issues.apache.org/jira/browse/DERBY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2128: -- Attachment: d2128.diff I think we should fix this in the code, and not in the message files. Although removing the word 'class' from the message files works for English, it doesn't for other languages because (1) Class.toString() always uses the English word 'class', and (2) even if Class.toString() were localized, it wouldn't have enough context to use the correct grammatical form of 'class' or put the word the correct place in the sentence for all languages. The attached patch changes sysinfo/Main.java so that it uses Class.getName() instead of Class.toString() to get the name of the class. No message files need to be updated if we go for this change. The wrod class appears twice for the message SIF01.V Key: DERBY-2128 URL: https://issues.apache.org/jira/browse/DERBY-2128 Project: Derby Issue Type: Bug Components: Localization, Newcomer Affects Versions: 10.2.1.6 Reporter: Manjula Kutty Assignee: R VIDYA LAKSHMI Priority: Trivial Attachments: 2.JPG, d2128.diff, Derby-2128.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2128) The wrod class appears twice for the message SIF01.V
[ https://issues.apache.org/jira/browse/DERBY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] R VIDYA LAKSHMI updated DERBY-2128: --- Derby Info: [Patch Available] The wrod class appears twice for the message SIF01.V Key: DERBY-2128 URL: https://issues.apache.org/jira/browse/DERBY-2128 Project: Derby Issue Type: Bug Components: Localization, Newcomer Affects Versions: 10.2.1.6 Reporter: Manjula Kutty Assignee: R VIDYA LAKSHMI Priority: Trivial Attachments: 2.JPG, Derby-2128.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2128) The word 'class' appears twice for the message SIF01.V
[ https://issues.apache.org/jira/browse/DERBY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2128: -- Summary: The word 'class' appears twice for the message SIF01.V (was: The wrod class appears twice for the message SIF01.V) The word 'class' appears twice for the message SIF01.V -- Key: DERBY-2128 URL: https://issues.apache.org/jira/browse/DERBY-2128 Project: Derby Issue Type: Bug Components: Localization, Newcomer Affects Versions: 10.2.1.6 Reporter: Manjula Kutty Assignee: R VIDYA LAKSHMI Priority: Trivial Attachments: 2.JPG, d2128.diff, Derby-2128.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3001) SYSTABLES documentation for TABLETYPE should include 'A' (Synonym)
[ https://issues.apache.org/jira/browse/DERBY-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3001: -- Derby Info: (was: [Patch Available]) Great!. Thank you for your contribution. Committed revision 627336. SYSTABLES documentation for TABLETYPE should include 'A' (Synonym) -- Key: DERBY-3001 URL: https://issues.apache.org/jira/browse/DERBY-3001 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.1.4 Reporter: Kathey Marsden Assignee: Abhilash T.G Priority: Trivial Attachments: derby-3001.diff Add tabletype 'A' (SYNONYM) to doc at: http://db.apache.org/derby/manuals/reference/sqlj165.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Junit test problem
I made a code change and then when i run the junit test: org.apache.derbyTesting.functionTests.suites.All some 5 tests get passed and then some E occurs and then the test never gets further. No error message comes out too... This is the same state for 12 hours.. What could be the reason.?
[jira] Updated: (DERBY-2128) The wrod class appears twice for the message SIF01.V
[ https://issues.apache.org/jira/browse/DERBY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] R VIDYA LAKSHMI updated DERBY-2128: --- Attachment: Derby-2128.diff I made changes to the sysinfoMessages.properties sysinfoMessages_pl.propertiesfile. I just removed the word 'class' from sysinfoMessages.properties and word 'klasy' from sysinfoMessages_pl.properties. The wrod class appears twice for the message SIF01.V Key: DERBY-2128 URL: https://issues.apache.org/jira/browse/DERBY-2128 Project: Derby Issue Type: Bug Components: Localization, Newcomer Affects Versions: 10.2.1.6 Reporter: Manjula Kutty Assignee: R VIDYA LAKSHMI Priority: Trivial Attachments: 2.JPG, Derby-2128.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3289) Bracketed comments should be documented in the Derby Tools and Utilities Guide
[ https://issues.apache.org/jira/browse/DERBY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568495#action_12568495 ] Dyre Tjeldvoll commented on DERBY-3289: --- Oh, sorry. I looked at it myself I I thought it looked good, and since it had been almost 5 days without comments I just committed it. As I understand it, there is no statute of limitations on patches, even committed patches can (and should) be reviewed. Bracketed comments should be documented in the Derby Tools and Utilities Guide -- Key: DERBY-3289 URL: https://issues.apache.org/jira/browse/DERBY-3289 Project: Derby Issue Type: New Feature Components: Documentation Affects Versions: 10.4.0.0 Reporter: James F. Adams Assignee: Kim Haase Priority: Minor Fix For: 10.4.0.0 Attachments: DERBY-3289.diff, output1.txt, output2.txt, output3.txt, rtoolsijcomref16653.html Ij was modified by Derby-3242 to recognize bracketed comments. This new feature should be documented in the Derby Tools and Utilities Guide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Junit test problem
Hi Jazarine, Based on the limited info you provided, off the top of my head I'd say: - your code change has caused an infinite loop? - your code change caused derby to hang (deadlock?) Or you could be having some JVM problems, but that's more unlikely. Maybe if you share some more details about both your platform and the change you made, someone may be able to offer better help. I'll suggest you comment out/revert your changes and rerun the test on a clean sandbox to see if it was your changes or your environment :) BR, Thomas Jazarine Jamal wrote: I made a code change and then when i run the junit test: org.apache.derbyTesting.functionTests.suites.All some 5 tests get passed and then some E occurs and then the test never gets further. No error message comes out too... This is the same state for 12 hours.. What could be the reason.? -- Thomas Nielsen
Re: Junit test problem
Jazarine Jamal wrote: I made a code change and then when i run the junit test: org.apache.derbyTesting.functionTests.suites.All some 5 tests get passed and then some E occurs and then the test never gets further. No error message comes out too... This is the same state for 12 hours.. What could be the reason.? Hard to say, but it's probably an environment problem or your code change :) A few hints that can be helpful: * use jstack to see where in the (Derby) code the test run is stuck (doesn't always give helpful information) * use the graphical test runner to more quickly see which test fails/hang * re-run the test or subsuite to pinpoint the problematic area * run without your modifications to ensure there are no environment problems * use a debugger to step through the test In your case, I would start by investigating the tests that resulted in errors. If you don't know which tests these are, have a look at suites.All and start with the first suite added/run (note that JUnit does not guarantee ordering for all scenarios). In general, you can check the state of suites.All by looking at the daily test results or the tinderbox test results: http://dbtg.thresher.com/derby/test/ hth, see you have gotten more answers already as well :) -- Kristian
Re: Junit test problem
Jazarine Jamal wrote: I made a code change and then when i run the junit test: org.apache.derbyTesting.functionTests.suites.All some 5 tests get passed and then some E occurs and then the test never gets further. No error message comes out too... This is the same state for 12 hours.. What could be the reason.? I wouldn't be surprised if it is related to OutOfMemory problems. Try increasing the heap size for the jvm. With Suns jvms its these options: -Xmssizeset initial Java heap size -Xmxsizeset maximum Java heap size Vemund
[jira] Updated: (DERBY-1318) Add an upgrade test to verify that DataSources can be serialized by the previous release and then correctly deserialized by the current release
[ https://issues.apache.org/jira/browse/DERBY-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-1318: --- Attachment: serialized-data-sources.zip derby-1318-1b-for_comments.stat derby-1318-1b-for_comments.diff 'derby-1318-1b-for_comments.diff' is a slightly changed from 1a: * uses more specific versions (for instance 10.3.2.1 instead of 10.3) * improved documentation slightly * added a read method to SerializeDataSource.java, which prints information about the specified file. Also added the serialized data source files, which are not included in the diff because they are binary files. Add an upgrade test to verify that DataSources can be serialized by the previous release and then correctly deserialized by the current release --- Key: DERBY-1318 URL: https://issues.apache.org/jira/browse/DERBY-1318 Project: Derby Issue Type: Test Components: JDBC, Test Affects Versions: 10.2.1.6 Reporter: Rick Hillegas Attachments: derby-1318-1a-for_comments.diff, derby-1318-1a-for_comments.stat, derby-1318-1b-for_comments.diff, derby-1318-1b-for_comments.stat, serialized-data-sources.zip Currently, our DataSources are serializable in order to play well with JNDI. However, we have no upgrade test verifying that DataSource serialization works across release boundaries. We should add this case to our upgrade tests. Further recommendations by Dan: I do think though that upgrade testing recently brought into the mainline by Deepa should be enhanced to test: - serializing Derby''s data source implementations in 10.1 and seeing it unserializes with 10.2 (maybe into a BLOB column) - making a Reference object out of Derby''s data source implementations in 10.1 and making it into an object with 10.2. (if this type of tetsing makes sense for References') -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1318) Add an upgrade test to verify that DataSources can be serialized by the previous release and then correctly deserialized by the current release
[ https://issues.apache.org/jira/browse/DERBY-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-1318: --- Derby Info: (was: [Patch Available]) Fix Version/s: 10.4.0.0 Committed 'derby-1318-1b-for_comments.diff' (and 'serialized-data-sources.zip') to trunk with revision 627356. Add an upgrade test to verify that DataSources can be serialized by the previous release and then correctly deserialized by the current release --- Key: DERBY-1318 URL: https://issues.apache.org/jira/browse/DERBY-1318 Project: Derby Issue Type: Test Components: JDBC, Test Affects Versions: 10.2.1.6 Reporter: Rick Hillegas Fix For: 10.4.0.0 Attachments: derby-1318-1a-for_comments.diff, derby-1318-1a-for_comments.stat, derby-1318-1b-for_comments.diff, derby-1318-1b-for_comments.stat, serialized-data-sources.zip Currently, our DataSources are serializable in order to play well with JNDI. However, we have no upgrade test verifying that DataSource serialization works across release boundaries. We should add this case to our upgrade tests. Further recommendations by Dan: I do think though that upgrade testing recently brought into the mainline by Deepa should be enhanced to test: - serializing Derby''s data source implementations in 10.1 and seeing it unserializes with 10.2 (maybe into a BLOB column) - making a Reference object out of Derby''s data source implementations in 10.1 and making it into an object with 10.2. (if this type of tetsing makes sense for References') -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3213) SQLChar.trim method is unused and could be removed
[ https://issues.apache.org/jira/browse/DERBY-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568517#action_12568517 ] Dyre Tjeldvoll commented on DERBY-3213: --- I can confirm that suites.All and derbyall both pass with this patch applied. +1 SQLChar.trim method is unused and could be removed -- Key: DERBY-3213 URL: https://issues.apache.org/jira/browse/DERBY-3213 Project: Derby Issue Type: Improvement Components: Newcomer, SQL Reporter: Bryan Pendleton Assignee: Deepthi Devaki A R Priority: Minor Attachments: DERBY-3213.diff As part of researching DERBY-2352, I came to the conclusion that the trim() method in SQLChar.java is no longer used, and could be removed. It appears that all calls to this method have been switched to call ansiTrim() instead. Hopefully, this just requires removing the code from SQLChar.java and StringDataValue.java, and running all the tests to verify that nothing is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12568520#action_12568520 ] Øystein Grøvlen commented on DERBY-2892: I have tested the patch with the repro attached here: http://www.nabble.com/Re%3A-Iterating-through-large-result-set-in-network-mode-causes-OutOfMemoryException-p15364393.html This repro does not access the blob columns that are selected, and it turns out that with the current patch, the blob objects are not released, and OOM error occurs. If I add a call to ResultSet#getBytes for each row, the OOM error does not occur. 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 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.2.2.1 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] Assigned: (DERBY-2993) Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual
[ https://issues.apache.org/jira/browse/DERBY-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G reassigned DERBY-2993: --- Assignee: Abhilash T.G Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual - Key: DERBY-2993 URL: https://issues.apache.org/jira/browse/DERBY-2993 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefjdbc77156.html Reporter: Tomohito Nakayama Assignee: Abhilash T.G Priority: Minor In the table of JDBC 2.0 ResultSet Methods Supported, there exists two rows of beforeFirst(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3397) Derby 10.3.1.4 and 10.3.2.1 break scrollable result sets? Hibernate Query.setFirstResult and/or setMaxResults
[
https://issues.apache.org/jira/browse/DERBY-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568529#action_12568529
]
Dag H. Wanvik commented on DERBY-3397:
--
If you can produce a plain SQL repro (or even a simple repro
using Hibernate) it would help a lot!
I am not familiar with the Hibernate mapping, so it would be nice if you could
trace
the relevant SQL being executed here (server traceing):
by setting derby.language.logStatementText=true
and derby.stream.error.logSeverityLevel=0
The trace output can be found in derby.log; it would be helpful if you could
attach that trace to this issue.
a) Is the scrollable result set also updatable?
b) Do you use the Derby network client driver or do you run embedded Derby?
If you use the client driver, you could trace there also, see
http://db.apache.org/derby/docs/10.3/adminguide/cadminappsclienttracing.html
c) Do the rows in OURTABLE contain any LOB objects (LOBS, CLOBS)?
Derby 10.3.1.4 and 10.3.2.1 break scrollable result sets? Hibernate
Query.setFirstResult and/or setMaxResults
-
Key: DERBY-3397
URL: https://issues.apache.org/jira/browse/DERBY-3397
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.1.4, 10.3.2.1
Environment: Derby 10.3.1.4 and 10.3.2.1, Hibernate 3.2.5
Reporter: Michael Lossos
Priority: Critical
I am attempting to upgrade our product from Derby 10.2.2.0 to 10.3.2.1. With
all other things held constant, if I change the derby.jar from 10.2.2 to
10.3.2.1, our calls to set the (JDBC) first result and max results (max rows)
no longer function properly, such that no results are returned beyond first
result 200, max results 100 (max rows 300), even when the table has over 1000
rows. 2 of the 11 columns of this table are indexed
We use Hibernate's result pagination via Query.setFirstResult and
setMaxResults which, in org.hibernate.loader.Loader.advance(), uses
java.sql.ResultSet.advance when scrollable result sets are available, and as
expected org.apache.derby.impl.jdbc.EmbedDatabaseMetaData reports that
scrollable result sets are available for both Derby 10.2.2 and 10.3.2.1.
The following is pseudo code for what we're doing with Hibernate:
int pageSize = 100;
int count = ... // select count(*) from OURTABLE;
for( int firstResult = 0; firstResult count; firstResult += pageSize) {
Query query = session.createQuery( from OurHibernateObject); //
select * from OURTABLE
query.setFirstResult( firstResult );
query.setMaxResults( pageSize );
List objList = query.list();
// results are fine for firstResult 100 and 200,
// but beyond that no results are returned with a 1000 row table!
}
When settings max results, Hibernate correctly sets max rows as follows from
org.hibernate.loader.Loader.setMaxRows:
st.setMaxRows( selection.getMaxRows().intValue() + getFirstRow( selection ) );
Which is calling into org.apache.derby.impl.jdbc.EmbedPreparedStatement40.
This code path doesn't change between Derby 10.2.2 and 10.3.2.1.
I've tried completely recreating the database to remove any possible problems
with soft / full upgrades, but this didn't fix the problem. I tried 10.3.1.4
but this also exhibits the bug.
This seems like a fairly basic regression (surely a Derby test would fail if
scrollable results were broken). I'm wondering if there's another factor at
work here? Please help me to describe whatever else is necessary for you to
reproduce this. (I can't post our table schema or our code.) I apologize in
advance if this our own mistake but as I said, I'm only updating the
derby.jar.
Thanks for all the hard work on Derby!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2012) The Syntax of the UPDATE and DELETE statements is not correct in the reference manual
[ https://issues.apache.org/jira/browse/DERBY-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G reassigned DERBY-2012: --- Assignee: Abhilash T.G The Syntax of the UPDATE and DELETE statements is not correct in the reference manual - Key: DERBY-2012 URL: https://issues.apache.org/jira/browse/DERBY-2012 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Christian d'Heureuse Assignee: Abhilash T.G Priority: Minor The syntax description of the UPDATE and DELETE statements in the reference manual does not imply that an alias name may be specified for the table name. The statements are currently documented as: UPDATE table-Name SET ... DELETE FROM table-Name [ WHERE ... ] This should be changed to: UPDATE table-Name [ [ AS ] correlation-Name ] SET ... DELETE FROM table-Name [ [ AS ] correlation-Name ] [ WHERE ... ] (Table alias names for UPDATE and DELETE are important for the WHERE clauses, e.g. when the same table is used a second time within a subquery in the WHERE condition, e.g.: UPDATE table1 a SET ... WHERE EXISTS ( SELECT * FROM table1 b WHERE a.field1 = b.field2 ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3325) Add 'maxStatements' property to ClientConnectionPoolDataSource
[ https://issues.apache.org/jira/browse/DERBY-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3325: --- Attachment: derby-3325-2a-enable_test_and_remove_workaround.diff 'derby-3325-2a-enable_test_and_remove_workaround.diff' enables the test in jdbcapi._Suite forJDBC 3.0+ environments. In addition, it removes the workaround for bug DERBY-3306, cleans up some JavaDoc tags and removes two unused imports in _Suite. Add 'maxStatements' property to ClientConnectionPoolDataSource -- Key: DERBY-3325 URL: https://issues.apache.org/jira/browse/DERBY-3325 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: DataSourceReferenceTest.diff, DataSourceReferenceTest.java, derby-3325-1a-maxStatements.diff, derby-3325-1a-maxStatements.stat, derby-3325-1b-maxStatements.diff, derby-3325-1b-maxStatements.stat, derby-3325-2a-enable_test_and_remove_workaround.diff The classes in Derby implementing javax.sql.ConnectionPoolDataSource must provide setter and getter methods for the property 'maxStatements'. This property is used to control the whether the data source should produce pooled connections with statement cache capabilities or not, and how big the statement cache is allowed to be. This issue only deals with the client JDBC driver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3325) Add 'maxStatements' property to ClientConnectionPoolDataSource
[ https://issues.apache.org/jira/browse/DERBY-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3325: --- Derby Info: (was: [Patch Available]) Committed 'derby-3325-1b-maxStatements.diff' to trunk with revision 627380. The new test still has to be enabled. Add 'maxStatements' property to ClientConnectionPoolDataSource -- Key: DERBY-3325 URL: https://issues.apache.org/jira/browse/DERBY-3325 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: DataSourceReferenceTest.diff, DataSourceReferenceTest.java, derby-3325-1a-maxStatements.diff, derby-3325-1a-maxStatements.stat, derby-3325-1b-maxStatements.diff, derby-3325-1b-maxStatements.stat The classes in Derby implementing javax.sql.ConnectionPoolDataSource must provide setter and getter methods for the property 'maxStatements'. This property is used to control the whether the data source should produce pooled connections with statement cache capabilities or not, and how big the statement cache is allowed to be. This issue only deals with the client JDBC driver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3105) No documentation of ij -ca option
[ https://issues.apache.org/jira/browse/DERBY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G reassigned DERBY-3105: --- Assignee: Abhilash T.G No documentation of ij -ca option - Key: DERBY-3105 URL: https://issues.apache.org/jira/browse/DERBY-3105 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.1.4 Reporter: Sebb Assignee: Abhilash T.G Priority: Minor The ij tool gives the following help output: Usage: java org.apache.derby.tools.ij [-p propertyfile] [-ca connectionAttributePropertyFile] [inputfile] The -p flag and inputfile are documented in derbytools.pdf, but the -ca flag does not seem to be documented anywhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2320) Example in DEGREES function is not appropriate.
[ https://issues.apache.org/jira/browse/DERBY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Bhaskaran updated DERBY-2320: -- Attachment: DERBY-2320.diff Example in DEGREES function is not appropriate. Key: DERBY-2320 URL: https://issues.apache.org/jira/browse/DERBY-2320 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rreffuncdegrees.html Reporter: Tomohito Nakayama Assignee: Abhishek Bhaskaran Priority: Minor Attachments: DERBY-2320.diff, rreffuncdegrees.html In the description of DEGREES function in Derby Reference Manual, next description exists. Attention: The conversion from radians to degrees is not exact. You should not expect that the COS(RADIANS(90.0)) to exactly equal 0.0. Because the page is for DEGREES function , example here should be DEGREES( ACOS( 0 ) ) and 90.0 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2320) Example in DEGREES function is not appropriate.
[ https://issues.apache.org/jira/browse/DERBY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Bhaskaran updated DERBY-2320: -- Attachment: (was: DERBY-2320.diff) Example in DEGREES function is not appropriate. Key: DERBY-2320 URL: https://issues.apache.org/jira/browse/DERBY-2320 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rreffuncdegrees.html Reporter: Tomohito Nakayama Assignee: Abhishek Bhaskaran Priority: Minor Attachments: DERBY-2320.diff, rreffuncdegrees.html In the description of DEGREES function in Derby Reference Manual, next description exists. Attention: The conversion from radians to degrees is not exact. You should not expect that the COS(RADIANS(90.0)) to exactly equal 0.0. Because the page is for DEGREES function , example here should be DEGREES( ACOS( 0 ) ) and 90.0 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2320) Example in DEGREES function is not appropriate.
[ https://issues.apache.org/jira/browse/DERBY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Bhaskaran updated DERBY-2320: -- Attachment: (was: rreffuncdegrees.dita) Example in DEGREES function is not appropriate. Key: DERBY-2320 URL: https://issues.apache.org/jira/browse/DERBY-2320 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rreffuncdegrees.html Reporter: Tomohito Nakayama Assignee: Abhishek Bhaskaran Priority: Minor Attachments: DERBY-2320.diff, rreffuncdegrees.html In the description of DEGREES function in Derby Reference Manual, next description exists. Attention: The conversion from radians to degrees is not exact. You should not expect that the COS(RADIANS(90.0)) to exactly equal 0.0. Because the page is for DEGREES function , example here should be DEGREES( ACOS( 0 ) ) and 90.0 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2320) Example in DEGREES function is not appropriate.
[ https://issues.apache.org/jira/browse/DERBY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Bhaskaran updated DERBY-2320: -- Attachment: (was: rreffuncdegrees.html) Example in DEGREES function is not appropriate. Key: DERBY-2320 URL: https://issues.apache.org/jira/browse/DERBY-2320 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rreffuncdegrees.html Reporter: Tomohito Nakayama Assignee: Abhishek Bhaskaran Priority: Minor Attachments: DERBY-2320.diff, rreffuncdegrees.html In the description of DEGREES function in Derby Reference Manual, next description exists. Attention: The conversion from radians to degrees is not exact. You should not expect that the COS(RADIANS(90.0)) to exactly equal 0.0. Because the page is for DEGREES function , example here should be DEGREES( ACOS( 0 ) ) and 90.0 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2548) NullPointerException through client/am/EncryptionManager
[ https://issues.apache.org/jira/browse/DERBY-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G updated DERBY-2548: Attachment: (was: DERBY-1400.diff) NullPointerException through client/am/EncryptionManager Key: DERBY-2548 URL: https://issues.apache.org/jira/browse/DERBY-2548 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Reporter: Myrna van Lunteren Assignee: Abhilash T.G Priority: Trivial Encountered a NullPointerException that doesn't make it to the enduser / application while debugging test jdbcapi/DataSourceTest in one of my eclipse workspaces: org/apache/derby/client/am/EncryptionManager; constructor: public EncryptionManager(Agent agent) : throw new SqlException(agent_.logWriter_, agent_ was null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2320) Example in DEGREES function is not appropriate.
[ https://issues.apache.org/jira/browse/DERBY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Bhaskaran updated DERBY-2320: -- Attachment: rreffuncdegrees.html Example in DEGREES function is not appropriate. Key: DERBY-2320 URL: https://issues.apache.org/jira/browse/DERBY-2320 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rreffuncdegrees.html Reporter: Tomohito Nakayama Assignee: Abhishek Bhaskaran Priority: Minor Attachments: DERBY-2320.diff, rreffuncdegrees.html In the description of DEGREES function in Derby Reference Manual, next description exists. Attention: The conversion from radians to degrees is not exact. You should not expect that the COS(RADIANS(90.0)) to exactly equal 0.0. Because the page is for DEGREES function , example here should be DEGREES( ACOS( 0 ) ) and 90.0 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2320) Example in DEGREES function is not appropriate.
[ https://issues.apache.org/jira/browse/DERBY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Bhaskaran updated DERBY-2320: -- Attachment: rreffuncdegrees.dita Example in DEGREES function is not appropriate. Key: DERBY-2320 URL: https://issues.apache.org/jira/browse/DERBY-2320 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rreffuncdegrees.html Reporter: Tomohito Nakayama Assignee: Abhishek Bhaskaran Priority: Minor Attachments: DERBY-2320.diff, rreffuncdegrees.dita, rreffuncdegrees.html In the description of DEGREES function in Derby Reference Manual, next description exists. Attention: The conversion from radians to degrees is not exact. You should not expect that the COS(RADIANS(90.0)) to exactly equal 0.0. Because the page is for DEGREES function , example here should be DEGREES( ACOS( 0 ) ) and 90.0 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen updated DERBY-2998: -- Attachment: d2998-test4.stat d2998-test4.diff Attaching updates to the OLAPTest in 'd2998-test4.diff'. This is a collection of the different queries that have been reported to fail, as well as a couple of other verification queries. The test4 patch makes OLAPTest contain 13 queries expected to pass, and 3 expected to fail. Add support for ROW_NUMBER() window function Key: DERBY-2998 URL: https://issues.apache.org/jira/browse/DERBY-2998 Project: Derby Issue Type: Sub-task Components: SQL Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Minor Attachments: d2998-10.diff, d2998-10.stat, d2998-11.diff, d2998-4.diff, d2998-4.stat, d2998-5.diff, d2998-5.stat, d2998-6.diff, d2998-6.stat, d2998-7.diff, d2998-7.stat, d2998-8.diff, d2998-8.stat, d2998-9-derby.log, d2998-9.diff, d2998-9.stat, d2998-doc-1.diff, d2998-doc-1.stat, d2998-test.diff, d2998-test.stat, d2998-test2.diff, d2998-test2.stat, d2998-test3.diff, d2998-test3.stat, d2998-test4.diff, d2998-test4.stat As part of implementing the overall OLAP Operations features of SQL (DERBY-581), implement the ROW_NUMBER() window function. More information about this feature is available at http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen updated DERBY-2998: -- Attachment: d2998-12.stat d2998-12.diff Attaching 'd2998-12.diff' patch that fixes the problems also seen by Army. - queries ordered on a column left out of the projection - incorrect results due to incorrect column mapping - the assert due to incorrect column mapping The 16 queries in my previously attached test4 patch run successfully, and the lang/_Suite runs without failures. There's still a problem with the column mapping if you do multiple window functions in a single RCL. If you happen to play with this and see failing queries, please let me know. Add support for ROW_NUMBER() window function Key: DERBY-2998 URL: https://issues.apache.org/jira/browse/DERBY-2998 Project: Derby Issue Type: Sub-task Components: SQL Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Minor Attachments: d2998-10.diff, d2998-10.stat, d2998-11.diff, d2998-12.diff, d2998-12.stat, d2998-4.diff, d2998-4.stat, d2998-5.diff, d2998-5.stat, d2998-6.diff, d2998-6.stat, d2998-7.diff, d2998-7.stat, d2998-8.diff, d2998-8.stat, d2998-9-derby.log, d2998-9.diff, d2998-9.stat, d2998-doc-1.diff, d2998-doc-1.stat, d2998-test.diff, d2998-test.stat, d2998-test2.diff, d2998-test2.stat, d2998-test3.diff, d2998-test3.stat, d2998-test4.diff, d2998-test4.stat As part of implementing the overall OLAP Operations features of SQL (DERBY-581), implement the ROW_NUMBER() window function. More information about this feature is available at http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2128) The word 'class' appears twice for the message SIF01.V
[ https://issues.apache.org/jira/browse/DERBY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568548#action_12568548 ] R VIDYA LAKSHMI commented on DERBY-2128: Yes that is correct. I think what Knut said is right and the diff file attached is right. Awaiting commitment. The word 'class' appears twice for the message SIF01.V -- Key: DERBY-2128 URL: https://issues.apache.org/jira/browse/DERBY-2128 Project: Derby Issue Type: Bug Components: Localization, Newcomer Affects Versions: 10.2.1.6 Reporter: Manjula Kutty Assignee: R VIDYA LAKSHMI Priority: Trivial Attachments: 2.JPG, d2128.diff, Derby-2128.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3402) Publish Japanese translated manual at documentation page.
[ https://issues.apache.org/jira/browse/DERBY-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomohito Nakayama updated DERBY-3402: - Attachment: index.html DERBY-3402.patch Description of patch : * Add link to Japanese translated reference manual file in alpha version. Test : * Execute forrest and confirm manuals/index.html have no problem. Publish Japanese translated manual at documentation page. - Key: DERBY-3402 URL: https://issues.apache.org/jira/browse/DERBY-3402 Project: Derby Issue Type: Sub-task Environment: http://db.apache.org/derby/manuals/index.html Reporter: Tomohito Nakayama Attachments: DERBY-3402.patch, index.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2872) Add Replication functionality to Derby
[ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568577#action_12568577 ] Jørgen Løland commented on DERBY-2872: -- Code freeze for 10.4 is getting closer by the minute. It would be good to evaluate the funcspec at this point and be explicit about which replication features will make it into this release and which will be delayed for the next. As I see it, the following will have to be delayed until 10.5: * CLI for NetworkServerControl (this has already been mentioned in the funcspec) * Depending on ETA of DERBY-2109, the system privilege for replication may or may not make it into 10.4 * Copy the database from the master to the slave inside Derby by using the master-slave network connection. Instead, a file system copy of the database to the slave location will be required before replication can be started. This has the implication that startup of replication requires these steps: 1) boot database 'x' on master 2) freeze 'x' (force log and data to disk and block write operations) 3) copy 'x' to slave location using file system copy 4) connect to 'x' with startSlave option on Derby serving slave 5) connect to 'x' with startMaster option on Derby serving master (includes unfreeze of 'x') ...as opposed to only doing the originally intended steps 4 and 5. FWIW, startup of replication in MySQL requires a similar file system copy of the database. Of course, both these issues can be addressed in 10.4 if someone volunteers to work on them. I will update the funcspec with this information in a few days unless I hear objections. Add Replication functionality to Derby -- Key: DERBY-2872 URL: https://issues.apache.org/jira/browse/DERBY-2872 Project: Derby Issue Type: New Feature Components: Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: master_classes_1.pdf, poc_master_v2.diff, poc_master_v2.stat, poc_master_v2b.diff, poc_slave_v2.diff, poc_slave_v2.stat, poc_slave_v2b.diff, poc_slave_v2c.diff, proof-of-concept_v2b-howto.txt, proof_of_concept_master.diff, proof_of_concept_master.stat, proof_of_concept_slave.diff, proof_of_concept_slave.stat, replication_funcspec.html, replication_funcspec_v2.html, replication_funcspec_v3.html, replication_funcspec_v4.html, replication_funcspec_v5.html, replication_funcspec_v6.html, replication_funcspec_v7.html, replication_funcspec_v8.html, replication_script.txt, slave_classes_1.pdf It would be nice to have replication functionality to Derby; many potential Derby users seem to want this. The attached functional specification lists some initial thoughts for how this feature may work. Dag Wanvik had a look at this functionality some months ago. He wrote a proof of concept patch that enables replication by copying (using file system copy) and redoing the existing Derby transaction log to the slave (unfortunately, I can not find the mail thread now). DERBY-2852 contains a patch that enables replication by sending dedicated logical log records to the slave through a network connection and redoing these. Replication has been requested and discussed previously in multiple threads, including these: http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/[EMAIL PROTECTED] http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3014) Make SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.username') return NULL instead of the hash value of the password
[
https://issues.apache.org/jira/browse/DERBY-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568558#action_12568558
]
Jazarine Jamal commented on DERBY-3014:
---
A call to SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.username')
property returns NULL evenn if the username does not exist.
So, I was thinking if the system function returns a ** instead of null.
Make SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.username') return
NULL instead of the hash value of the password
---
Key: DERBY-3014
URL: https://issues.apache.org/jira/browse/DERBY-3014
Project: Derby
Issue Type: Improvement
Components: Security
Reporter: Daniel John Debrunner
Assignee: R VIDYA LAKSHMI
Increases security by providing less information to any attacker. The current
returned hash value could be used in an off-line dictionary based attack to
find a valid password.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2993) Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual
[ https://issues.apache.org/jira/browse/DERBY-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G updated DERBY-2993: Attachment: DERBY-2993.diff I've removed the duplicate entry for beforeFirst() in rrefjdbc77156.dita. I generated the html book and pdf for this and the changes are reflected in the page. Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual - Key: DERBY-2993 URL: https://issues.apache.org/jira/browse/DERBY-2993 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefjdbc77156.html Reporter: Tomohito Nakayama Assignee: Abhilash T.G Priority: Minor Attachments: DERBY-2993.diff In the table of JDBC 2.0 ResultSet Methods Supported, there exists two rows of beforeFirst(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2993) Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual
[ https://issues.apache.org/jira/browse/DERBY-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G updated DERBY-2993: Derby Info: [Patch Available] Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual - Key: DERBY-2993 URL: https://issues.apache.org/jira/browse/DERBY-2993 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefjdbc77156.html Reporter: Tomohito Nakayama Assignee: Abhilash T.G Priority: Minor Attachments: DERBY-2993.diff In the table of JDBC 2.0 ResultSet Methods Supported, there exists two rows of beforeFirst(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568593#action_12568593 ] Dyre Tjeldvoll commented on DERBY-3404: --- The same thing happens if you turn off autocommit and issue a commit instead of executing 'values 1'. I.e. Class.forName(org.apache.derby.jdbc.EmbeddedDriver); Connection c = DriverManager.getConnection(jdbc:derby:db;create=true); c.setAutoCommit(false); Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); System.out.println(before ac: +rs.getString(1)); c.commit(); //c.createStatement().executeQuery(values 1).close(); // auto-commit System.out.println(after ac:+rs.getString(1)); But I don't really have any idea about where the connection is supposed to check/close result sets opened with ResultSet.CLOSE_CURSORS_AT_COMMIT EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3379) No Current connection on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing
[ https://issues.apache.org/jira/browse/DERBY-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568594#action_12568594 ] Knut Anders Hatlen commented on DERBY-3379: --- The 1b patch conflicts with the latest changes in DataSourceTest (testPooledReuseOnClose() has been moved to J2EEDataSourceTest) and doesn't apply cleanly. No Current connection on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing - Key: DERBY-3379 URL: https://issues.apache.org/jira/browse/DERBY-3379 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 Reporter: Kathey Marsden Assignee: Kristian Waagan Attachments: derby-3379-1a-enforce_no_chaining.diff, derby-3379-1a-enforce_no_chaining.diff, derby-3379-1a-enforce_no_chaining.stat, derby-3379-1a-enforce_no_chaining.stat, derby-3379-1b-enforce_no_chaining.diff This is the client version of bug DERBY-2142. It can be reproduced by enabling the test, DataSourceTest.testPooledReuseOnClose() for client. I am opening a new issue for client as the embedded fix was backported to 10.1 and I am guessing the client fix won't be backported that far. Better to keep it as a separate issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trouble getting jvm options to work with suites
Kathey Marsden wrote: I don't think the tests fork a process or anything so I don't understand how I could be losing the -Xjit:count=0 option. Does anyone have any idea what might be going on? Most likely the jit is performing a further optimization (ie. a recompile) on the method and producing a correct result. A modern jit does not have a 1-1 mapping between byte code and optimized code. Dan.
[jira] Issue Comment Edited: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568599#action_12568599 ] knutanders edited comment on DERBY-3404 at 2/13/08 8:00 AM: I'm wondering if perhaps the correct thing to do is to check theResults.isClosed() in EmbedResultSet.checkIfClosed(). I tried it and got this exception: Exception in thread main java.sql.SQLException: ResultSet not open. Operation 'getString' not permitted. Verify that autocommit is OFF. This is similar to what happens on the client driver, and I believe this is the correct behaviour. was (Author: knutanders): I'm wondering if perhaps the correct thing to do is to check theResults.isClosed() in EmbedResultSet.close(). I tried it and got this exception: Exception in thread main java.sql.SQLException: ResultSet not open. Operation 'getString' not permitted. Verify that autocommit is OFF. This is similar to what happens on the client driver, and I believe this is the correct behaviour. EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Schema Creation
Hi, I just wanted to know this. In the embedded ij tool, is a schema created when the user is created, or at some later point of time?
[jira] Commented: (DERBY-3408) Wrong message when using SHOW in ij.
[ https://issues.apache.org/jira/browse/DERBY-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568614#action_12568614 ] John H. Embretsen commented on DERBY-3408: -- Although the current error message is not necessarily wrong, I certainly agree that it is not helpful at all, and should be improved. Wrong message when using SHOW in ij. Key: DERBY-3408 URL: https://issues.apache.org/jira/browse/DERBY-3408 Project: Derby Issue Type: Bug Components: SQL Reporter: Jazarine Jamal Priority: Minor When running the show command using ij, it gives out a wrong message. eg.: ij show schema; ERROR 42X01: Syntax error: Encountered show at line 2, column 1. The message should be something like: Syntax error: Encountered schema at line 2,column 1:no such thing as schema -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Opinions please - some questions regarding replication
Hi Jørgen,
Some unscientific ramblings of a layman follow...
Jørgen Løland wrote:
I have a few questions regarding replication that would be great
to hear the community's opinion on before the 10.4 branching. The
reason for bringing this up before code freeze is that these will
have impact on existing applications if changed later.
1. The master of a replicated database ships log records and
other information to the slave through a network socket. 8001
is currently default port for this communication. From
http://www.iana.org/assignments/port-numbers it seems that
this port is reserved for
vcom-tunnel8001/tcpVCOM Tunnel
vcom-tunnel8001/udpVCOM Tunnel
Should we change port, and maybe even register a port in IANA,
or is it fine as it is? I have no idea how long it will take
to register a port, but chances are it will be longer than the
time we have for 10.4 with the current plan. Another
alternative is to use a port from the range called dynamic
and/or private ports (49152 through 65535) BTW: I noticed
that 1527 is registered by Oracle, which may also be a
problem?
At first blush, registering a port seems like a good idea. It ought to
reduce the likelihood of ugly surprises. I got the impression that the
top range ( dynamic and/or private ports) was for short-lived, transient
conversations. It's probably not the right range if you want to conduct
a long-running conversation on your port.
A little mousing around turned up these resources: The process for
registering a port is defined in section 19.9 of
http://www.rfc-editor.org/rfc/rfc4340.txt and the corresponding form is
at http://www.iana.org/cgi-bin/usr-port-number.pl It appears that IANA
wants to give you a port number rather than vice-versa. So if you want
to register a port, then our user documentation should say that the port
used in 10.4 is likely to change in a future release.
tlisrv 1527/tcporacle
tlisrv 1527/udporacle
Note that this is only a question of default port. The port
number may be set explicitly by the client starting
replication.
Oops. Changing this would be a backward compatibility issue and I doubt
you'll find much passion for this in the community.
2. About a week ago, Dibyendu Majumdar raised a question about
why the replication modules are placed under services and not
store. Should replication be moved from
org.apache.derby.{iapi|impl}.services.replication to e.g.
org.apache.derby.{iapi|impl}.store.replication, or is it OK to keep
the current placement?
3. Should replication be shipped in a separate JAR file? Pros and
cons as I see it:
+ Remove 65KB (unjared) of class files from derby.jar
+ Possible to have a different security policy file for replication?
- Yet another JAR file
This doesn't seem like excessive bloat to me.
Thanks,
-Rick
[jira] Created: (DERBY-3413) Derby crash in LockControl.isGrantable
Derby crash in LockControl.isGrantable -- Key: DERBY-3413 URL: https://issues.apache.org/jira/browse/DERBY-3413 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.3.1.4 Environment: Sun Solaris Sparc JVM 1.5.0-11 Reporter: Ludovic Pourrat The DERBY database server crashes sometimes on our production environment by producing a hs_err_pid file. After recycling our application the same process come throught. On the client side all the DERBY connections are loss. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Broken target 'ant javadoc'
Hello, My commit for DERBY-1318 broke the target 'javadoc', more specifically 'testing-javadoc'. The reason seems to be that the directory 'serialized-data-sources' is not a valid Java package name. My question is, which solution should I choose to fix the problem: a) Renamed the directory (i.e. 'serializedDataSources') b) Change the target to not generate JavaDoc for the testData directory (can be done by adding it to an exclude list). c) Should the test data be moved outside the source tree? Any opinions? If I don't get any feedback, I think I'll go for option a just because it's simple. thanks, -- Kristian
[jira] Updated: (DERBY-3408) Wrong message when using SHOW in ij.
[ https://issues.apache.org/jira/browse/DERBY-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-3408: -- Priority: Minor (was: Major) Wrong message when using SHOW in ij. Key: DERBY-3408 URL: https://issues.apache.org/jira/browse/DERBY-3408 Project: Derby Issue Type: Bug Components: SQL Reporter: Jazarine Jamal Priority: Minor When running the show command using ij, it gives out a wrong message. eg.: ij show schema; ERROR 42X01: Syntax error: Encountered show at line 2, column 1. The message should be something like: Syntax error: Encountered schema at line 2,column 1:no such thing as schema -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568599#action_12568599 ] Knut Anders Hatlen commented on DERBY-3404: --- I'm wondering if perhaps the correct thing to do is to check theResults.isClosed() in EmbedResultSet.close(). I tried it and got this exception: Exception in thread main java.sql.SQLException: ResultSet not open. Operation 'getString' not permitted. Verify that autocommit is OFF. This is similar to what happens on the client driver, and I believe this is the correct behaviour. EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3412) junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedErro
[ https://issues.apache.org/jira/browse/DERBY-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568601#action_12568601 ] Daniel John Debrunner commented on DERBY-3412: -- The point I was making is that what ever is running this test is setting a classpath that needlessly contains jar files that are automatically included by others. It's not a matter of how it's reported, just that the user's classpath could be vastly simplified. junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError -- Key: DERBY-3412 URL: https://issues.apache.org/jira/browse/DERBY-3412 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: Java Version:J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: c:\jartest\weme6.1 Java classpath: c:/jartest/classes/derby.jar;c:/jartest/classes/derbyLocale_zh_TW.jar;c:/jartest/classes/derbyLocale_zh_CN.jar;c:/jartest/classes/derbyLocale_ru.jar;c:/jartest/classes/derbyLocale_pt_BR.jar;c:/jartest/classes/derbyLocale_pl.jar;c:/jartest/classes/derbyLocale_ko_KR.jar;c:/jartest/classes/derbyLocale_ja_JP.jar;c:/jartest/classes/derbyLocale_it.jar;c:/jartest/classes/derbyLocale_hu.jar;c:/jartest/classes/derbyLocale_fr.jar;c:/jartest/classes/derbyLocale_es.jar;c:/jartest/classes/derbyLocale_de_DE.jar;c:/jartest/classes/derbyLocale_cs.jar;c:/jartest/tools/java/junit.jar;c:/jartest/classes/derbytools.jar;c:/jartest/classes/derbyrun.jar;c:/jartest/classes/derbyTesting.jar;c:/jartest/classes/functionTests.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 2 Java user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\jartest\JarResults.2008-02-11\weme6.1_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 Reporter: Mike Matrigali 5 new failures as of 2/11/08 in the ScrollCursors2Test, only seen in j2me test: 1) testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testForwardOnlyNegative(ScrollCursors2Test.java:95) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testForwardOnlyPositive(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testForwardOnlyPositive(ScrollCursors2Test.java:263) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 3) testScrollInsensitivePositive(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testScrollInsensitivePositive(ScrollCursors2Test.java:352) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 4) testScrollInsensitiveNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at
Re: Schema Creation
Jazarine Jamal wrote: Hi, I just wanted to know this. In the embedded ij tool, is a schema created when the user is created, or at some later point of time? With Derby, the schema can either be created explicitly by a CREATE SCHEMA statement or implicitly by creating an object (table etc.) in that schema. See also: http://db.apache.org/derby/faq.html#schema_exist This has the odd side-effect that in some special circumstances your default schema may not exist yet even if you have a valid connection to the database. -- John
[jira] Updated: (DERBY-3413) Derby crash in LockControl.isGrantable
[ https://issues.apache.org/jira/browse/DERBY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ludovic Pourrat updated DERBY-3413: --- Attachment: hs_err_pid23203.log Derby crash in LockControl.isGrantable -- Key: DERBY-3413 URL: https://issues.apache.org/jira/browse/DERBY-3413 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.3.1.4 Environment: Sun Solaris Sparc JVM 1.5.0-11 Reporter: Ludovic Pourrat Attachments: hs_err_pid23203.log The DERBY database server crashes sometimes on our production environment by producing a hs_err_pid file. After recycling our application the same process come throught. On the client side all the DERBY connections are loss. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2128) The word 'class' appears twice for the message SIF01.V
[ https://issues.apache.org/jira/browse/DERBY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen resolved DERBY-2128. --- Resolution: Fixed Fix Version/s: 10.4.0.0 Derby Info: (was: [Patch Available]) Thanks! Committed revision 627466. The word 'class' appears twice for the message SIF01.V -- Key: DERBY-2128 URL: https://issues.apache.org/jira/browse/DERBY-2128 Project: Derby Issue Type: Bug Components: Localization, Newcomer Affects Versions: 10.2.1.6 Reporter: Manjula Kutty Assignee: R VIDYA LAKSHMI Priority: Trivial Fix For: 10.4.0.0 Attachments: 2.JPG, d2128.diff, Derby-2128.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - Daily 620864 - Sun DBTG
[Auto-generated mail] *Daily* 620864/2008-02-12 18:01:03 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0271271 071.97% derbyall 01017910179 0 1295.12% suitesAll linN+1 0271271 0 110.43% derbyall 01017910179 0 117.65% suitesAll sles 1271270 074.33% derbyall 01017910179 0 910.05% suitesAll sol 0271271 075.75% derbyall 01017910179 0 1584.13% suitesAll solN+1 0271271 096.45% derbyall 01017910179 0 210.52% suitesAll sparc 0271271 065.71% derbyall 01017910179 0 359.91% suitesAll vista 0271271 092.50% derbyall 091549154 066.40% suitesAll w2003 0271271 096.50% derbyall 091549154 0 133.22% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-620864.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/620864_bySig.html *Jvm: 1.5* lin 0272272 071.53% derbyall NA NA NANA suitesAll linN+1 0272272 098.23% derbyall 084618461 0 117.36% suitesAll sles 0272272 069.92% derbyall 084618461 0 570.07% suitesAll sol 0272272 079.44% derbyall 084618461 0 854.21% suitesAll solN+1 0272272 087.77% derbyall 084618461 0 801.95% suitesAll sparc 0272272 066.42% derbyall 084618461 0 696.66% suitesAll vista 0272272 071.28% derbyall 074367436 0 406.49% suitesAll w2003 0272272 074.20% derbyall 074367436 0 259.28% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-620864.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/620864_bySig.html *Jvm: 1.4* lin 0269269 272.43% derbyall 084098409 0 807.86% suitesAll linN+1 0269269 299.39% derbyall 084098409 0 116.43% suitesAll sles 0269269 270.11% derbyall 084098409 0 529.68% suitesAll sol 0269269 277.84% derbyall 084098409 0 680.34% suitesAll solN+1 0269269 288.63% derbyall 084098409 0 752.08% suitesAll sparc 0269269 266.66% derbyall 084098409 0 697.01% suitesAll vista 0269269 271.08% derbyall 073847384 0 396.61% suitesAll w2003 0269269 274.89% derbyall 073887388 0 247.87% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-620864.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/620864_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/620864.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (13 issues) Subscriber: derby-dev Key Summary 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-2993 Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual https://issues.apache.org/jira/browse/DERBY-2993 DERBY-3213 SQLChar.trim method is unused and could be removed https://issues.apache.org/jira/browse/DERBY-3213 DERBY-3205 Replication: Add connection url command options for starting, stopping slave and for failover https://issues.apache.org/jira/browse/DERBY-3205 DERBY-3163 Derby JUnit test framework adaptions to run existing tests against replicated databases https://issues.apache.org/jira/browse/DERBY-3163 DERBY-3326 Introduce a caching logical connection and logical prepared statement in the client driver https://issues.apache.org/jira/browse/DERBY-3326 DERBY-1400 Cleanup code in network server's DRDAStatement class https://issues.apache.org/jira/browse/DERBY-1400 DERBY-2871 XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. https://issues.apache.org/jira/browse/DERBY-2871 DERBY-3382 Replication: Slave must inform master if DBs are out of sync. https://issues.apache.org/jira/browse/DERBY-3382 DERBY-3299 Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns. https://issues.apache.org/jira/browse/DERBY-3299 DERBY-2954 Add commands to NetworkServerControl for interacting with the replication functionality https://issues.apache.org/jira/browse/DERBY-2954 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] Commented: (DERBY-3413) Derby crash in LockControl.isGrantable
[ https://issues.apache.org/jira/browse/DERBY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568617#action_12568617 ] Ludovic Pourrat commented on DERBY-3413: See at http://forum.java.sun.com/thread.jspa?threadID=5119596messageID=9737995 Seems to be the same issue Derby crash in LockControl.isGrantable -- Key: DERBY-3413 URL: https://issues.apache.org/jira/browse/DERBY-3413 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.3.1.4 Environment: Sun Solaris Sparc JVM 1.5.0-11 Reporter: Ludovic Pourrat Attachments: hs_err_pid23203.log The DERBY database server crashes sometimes on our production environment by producing a hs_err_pid file. After recycling our application the same process come throught. On the client side all the DERBY connections are loss. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3413) Derby crash in LockControl.isGrantable
[ https://issues.apache.org/jira/browse/DERBY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568618#action_12568618 ] Knut Anders Hatlen commented on DERBY-3413: --- I believe this is the following JVM bug: http://bugs.sun.com/view_bug.do?bug_id=6519085 If that's the case, upgrading to the latest update of Java SE 5.0 should help (was fixed in update 14). Alternatively, you could try the workaround mentioned near the bottom of this page: http://forum.java.sun.com/thread.jspa?threadID=5119596messageID=9737995 Derby crash in LockControl.isGrantable -- Key: DERBY-3413 URL: https://issues.apache.org/jira/browse/DERBY-3413 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.3.1.4 Environment: Sun Solaris Sparc JVM 1.5.0-11 Reporter: Ludovic Pourrat Attachments: hs_err_pid23203.log The DERBY database server crashes sometimes on our production environment by producing a hs_err_pid file. After recycling our application the same process come throught. On the client side all the DERBY connections are loss. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3414) In Network server, rollback inside a java procedure does not close the resultsets created before the call to the java procedure.
In Network server, rollback inside a java procedure does not close the resultsets created before the call to the java procedure. Key: DERBY-3414 URL: https://issues.apache.org/jira/browse/DERBY-3414 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.3.2.1, 10.3.1.4, 10.2.2.0, 10.2.1.6 Reporter: Mamta A. Satoor Inside network server framework, if there is java procedure will rollback inside it, the rollback does not close the resultsets that were created before the call to java procedure was made. This happens in trunk, 10.3 and 10.2 codelines. I haven't tried earlier versions of Derby. In embedded mode, the resultsets (created before the call to java procedure) get closed when the rollback is done inside the java procedure. I will soon attach a standalone test case for this behavior. -- 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-3299) Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns.
[ https://issues.apache.org/jira/browse/DERBY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568630#action_12568630 ] army edited comment on DERBY-3299 at 2/13/08 9:07 AM: - I broke the single _v1 patch down into 4 smaller, relatively modular patches in hopes of making things easier for any potential reviewers. The patches are: 1. d3299_createIxAction_v1.patch: Changes/additions to CreateIndexConstantAction.java so that it can support the creation of replacement conglomerates, which will be necessary when the physical conglomerate for an index has been dropped but the index descriptor still exists. In that case we need to create a new physical conglomerate to support the existing descriptor. This can happen if multiple indexes share a physical conglomerate but then the conglomerate is dropped as part of drop index processing for one of the indexes. (Note that indexes here includes indexes which were created to back constraints). 2. d3299_caUtilMethods_v1.patch: Addition of utility methods to DDLSingleTableConstantAction.java that can be used by any ConstantAction classes which drop constraint or conglomerate descriptors. The methods recognize when a replacement conglomerate is needed and make the necessary calls to create such a conglomerate. See previous comment for details. 3. d3299_dropSharedConglom_v1.patch: Changes to ConglomerateDescriptor that include logic for detecting a replacement scenario, and logic to drop the old (shared) conglomerate in those scenarios. Also changes the various ConstantAction classes which rely on the drop() methods of ConglomerateDescriptor and ConstraintDescriptor to use the utility methods added as part of caUtilMethods_v1.patch. This is the patch which ultimately fixes this issue and activates the preceding two patches--and thus is the only one which changes the functional behavior of Derby. 4. d3299_tests_v1.patch: New JUnit tests for verifying the correct behavior when constraints share a physical conglomerate and then one of them is dropped. I'm attaching all 4 patches here, but plan to commit them one at a time, a day or two apart, to allow for any review comments/suggestions. In the absence of review comments I'll just go ahead and commit each one in its own time. As each patch is committed, the subsequent patches may need to be tweaked to allow for minor conflicts that exist between them. I will posted updated patches as necessary--but the _v1 patches should at least allow reviewers to see the changes and make comments. Note to any reviewers: the patches build on each other: i.e. attempts to apply and build patch #2 will fail unless patch #1 has been applied first. I ran derbyall with d3299_createIxAction_v1.patch and it ran cleanly; I'm currently running suites.All. If the latter passes, then I plan to commit that patch tomorrow (Thursday, Feb 14, PST). was (Author: army): I broke the single _v1 patch down into 4 smaller, relatively modular patches in hopes of making things easier for any potential reviewers. The patches are: 1. d3299_createIxAction_v1.patch: Changes/additions to CreateIndexConstantAction.java so that it can support the creation of replacement conglomerates, which will be necessary when the physical conglomerate for an index has been dropped but the index descriptor still exists. In that case we need to create a new physical conglomerate to support the existing descriptor. This can happen if multiple indexes share a physical conglomerate but then the conglomerate is dropped as part of drop index processing for one of the indexes. (Note that indexes here includes indexes which were created to back constraints). 2. d3299_caUtilMethods_v1.patch: Addition of utility methods to DDLSingleTableConstantAction.java that can be used by any ConstantAction classes which drop constraint or conglomerate descriptors. The methods recognize when a replacement conglomerate is needed and make the necessary calls to create such a conglomerate. See previous comment for details. 3. d3299_dropSharedConglom_v1.patch: Changes to ConglomerateDescriptor that include logic for detecting a replacement scenario, and logic to drop the old (shared) conglomerate in those scenarios. Also changes the various ConstantAction classes which rely on the drop() methods of ConglomerateDescriptor and ConstraintDescriptor to use the utility methods added as part of caUtilMethods_v1.patch. This is the patch which ultimately fixes this issue and activates the preceding two patches--and thus is the only one which changes the functional behavior of Derby. 4. d3299_tests_v1.patch: New JUnit tests for verifying the correct behavior when constraints share a physical conglomerate and then one of them is dropped. I'm attaching all 4 patches here, but plan to commit them one at a time, a
Re: Trouble getting jvm options to work with suites
Daniel John Debrunner wrote: Most likely the jit is performing a further optimization (ie. a recompile) on the method and producing a correct result. A modern jit does not have a 1-1 mapping between byte code and optimized code. Thanks Dan. I guess there is no way to thoroughly test the JIT then, but I will at least run the suite with -Xjit:count=0 and see if it pops anything. Kathey
[jira] Updated: (DERBY-3299) Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns.
[ https://issues.apache.org/jira/browse/DERBY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A B updated DERBY-3299: --- Attachment: d3299_tests_v1.patch Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns. --- Key: DERBY-3299 URL: https://issues.apache.org/jira/browse/DERBY-3299 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: A B Assignee: A B Priority: Minor Attachments: case_2.sql, d3299_caUtilMethods_v1.patch, d3299_createIxAction_v1.patch, d3299_dropSharedConglom_v1.patch, d3299_tests_v1.patch, d3299_v1.patch When there are multiple constraints on a single table and the constraints have the same set of columns (in the same order), Derby tries to optimize things by re-using a single backing index for all of the relevant constraints. See the executeConstantAction() method of CreateIndexConstantAction.java (search for duplicate). But there is a bug in Derby where, if one of the constraints is unique and is dropped, the uniqueness attribute of the backing index is not updated accordingly. This means that uniqueness may be incorrectly enforced where it is not required. Take the following example (Case 2 from DERBY-2204): ALTER TABLE NEWORDERS ADD CONSTRAINT NEWORDERS_PK PRIMARY KEY(NO_W_ID, NO_D_ID, NO_O_ID); ALTER TABLE NEWORDERS ADD CONSTRAINT NO_O_FK FOREIGN KEY (NO_W_ID, NO_D_ID, NO_O_ID) REFERENCES ORDERS; For these statements Derby will use a single backing index for both the primary constraint NEWORDERS_PK and the foreign key constraint NO_O_FK. That backing index will be unique because the primary key must itself be unique. If later we drop the primary key: ALTER TABLE NEWORDERS DROP CONSTRAINT NEWORDERS_PK; then the backing index needs to be converted from a unique index to a non-unique index (because a foreign key is not inherently unique). But in Derby the uniqueness attribute remains unchanged, so attempts to insert a duplicate (NO_W_ID, NO_D_ID, NO_O_ID) row into NEWORDERS will fail with error 23505, when it should really succeed. I tried this out on 10.1.3.1 and the same behavior occurs there, so marking Affects versions for everything back to that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3414) In Network server, rollback inside a java procedure does not close the resultsets created before the call to the java procedure.
[ https://issues.apache.org/jira/browse/DERBY-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-3414: --- Attachment: test_rollback_in_procedure.java This test program in it's current state is coded to run in Network server mode and one can see from the output of the test run that resultsets are left open after the rollback * Testing with jdbc:derby://localhost:1527/c:/dellater/db;create=true rs1 still open??? resultSet still open??? When the code is changed so it is run in embedded mode, the output is as follows which shows the expected behavior of resultset closing because of the rollback inside the java procedure * Testing with org.apache.derby.jdbc.EmbeddedDriver closed as expected rs1 closed as expected resultSet In Network server, rollback inside a java procedure does not close the resultsets created before the call to the java procedure. Key: DERBY-3414 URL: https://issues.apache.org/jira/browse/DERBY-3414 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 Reporter: Mamta A. Satoor Attachments: test_rollback_in_procedure.java Inside network server framework, if there is java procedure will rollback inside it, the rollback does not close the resultsets that were created before the call to java procedure was made. This happens in trunk, 10.3 and 10.2 codelines. I haven't tried earlier versions of Derby. In embedded mode, the resultsets (created before the call to java procedure) get closed when the rollback is done inside the java procedure. I will soon attach a standalone test case for this behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3299) Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns.
[ https://issues.apache.org/jira/browse/DERBY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A B updated DERBY-3299: --- Attachment: d3299_dropSharedConglom_v1.patch d3299_caUtilMethods_v1.patch d3299_createIxAction_v1.patch I broke the single _v1 patch down into 4 smaller, relatively modular patches in hopes of making things easier for any potential reviewers. The patches are: 1. d3299_createIxAction_v1.patch: Changes/additions to CreateIndexConstantAction.java so that it can support the creation of replacement conglomerates, which will be necessary when the physical conglomerate for an index has been dropped but the index descriptor still exists. In that case we need to create a new physical conglomerate to support the existing descriptor. This can happen if multiple indexes share a physical conglomerate but then the conglomerate is dropped as part of drop index processing for one of the indexes. (Note that indexes here includes indexes which were created to back constraints). 2. d3299_caUtilMethods_v1.patch: Addition of utility methods to DDLSingleTableConstantAction.java that can be used by any ConstantAction classes which drop constraint or conglomerate descriptors. The methods recognize when a replacement conglomerate is needed and make the necessary calls to create such a conglomerate. See previous comment for details. 3. d3299_dropSharedConglom_v1.patch: Changes to ConglomerateDescriptor that include logic for detecting a replacement scenario, and logic to drop the old (shared) conglomerate in those scenarios. Also changes the various ConstantAction classes which rely on the drop() methods of ConglomerateDescriptor and ConstraintDescriptor to use the utility methods added as part of caUtilMethods_v1.patch. This is the patch which ultimately fixes this issue and activates the preceding two patches--and thus is the only one which changes the functional behavior of Derby. 4. d3299_tests_v1.patch: New JUnit tests for verifying the correct behavior when constraints share a physical conglomerate and then one of them is dropped. I'm attaching all 4 patches here, but plan to commit them one at a time, a day or two apart, to allow for any review comments/suggestions. In the absence of review comments I'll just go ahead and commit each one in its own time. As each patch is committed, the subsequent patches may need to be tweaked to allow for minor conflicts that exist between them. I will posted updated patches as necessary--but the _v1 patches should at least allow reviewers to see the changes and make comments. Note to any reviewers: the patches build on each other: i.e. attempts to apply and build patch #2 will fail unless patch #1 has been applied first. I ran derbyall with d3288_createIxAction_v1.patch and it ran cleanly; I'm currently running suites.All. If the latter passes, then I plan to commit that patch tomorrow (Thursday, Feb 14, PST). Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns. --- Key: DERBY-3299 URL: https://issues.apache.org/jira/browse/DERBY-3299 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: A B Assignee: A B Priority: Minor Attachments: case_2.sql, d3299_caUtilMethods_v1.patch, d3299_createIxAction_v1.patch, d3299_dropSharedConglom_v1.patch, d3299_tests_v1.patch, d3299_v1.patch When there are multiple constraints on a single table and the constraints have the same set of columns (in the same order), Derby tries to optimize things by re-using a single backing index for all of the relevant constraints. See the executeConstantAction() method of CreateIndexConstantAction.java (search for duplicate). But there is a bug in Derby where, if one of the constraints is unique and is dropped, the uniqueness attribute of the backing index is not updated accordingly. This means that uniqueness may be incorrectly enforced where it is not required. Take the following example (Case 2 from DERBY-2204): ALTER TABLE NEWORDERS ADD CONSTRAINT NEWORDERS_PK PRIMARY KEY(NO_W_ID, NO_D_ID, NO_O_ID); ALTER TABLE NEWORDERS ADD CONSTRAINT NO_O_FK FOREIGN KEY (NO_W_ID, NO_D_ID, NO_O_ID) REFERENCES ORDERS; For these statements Derby will use a single backing index for both the primary constraint NEWORDERS_PK and the foreign key constraint NO_O_FK. That backing index will be unique because the primary key must itself be unique. If later we drop the primary key: ALTER TABLE NEWORDERS DROP CONSTRAINT NEWORDERS_PK; then
[jira] Updated: (DERBY-3400) testgetTypeInfo Fails with ibm16 while running the UpgradeTests
[ https://issues.apache.org/jira/browse/DERBY-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3400: -- Attachment: derby-3400_diff.txt Attached is a patch that changes the test to have a workaround for this issue. We create a separate array for ODBC nullability instead of doing arrayCopy and reassignment of values that are different. I am not sure how folks feel about checking in workarounds for JVM issues, so I will let this patch sit for a few days before I check in to see if there are any comments. testgetTypeInfo Fails with ibm16 while running the UpgradeTests --- Key: DERBY-3400 URL: https://issues.apache.org/jira/browse/DERBY-3400 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr1-20080108_02) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080102 _15870 (JIT enabled) J9VM - 20080102_015870_lHdSMr JIT - r9_20080101_1821 GC - 20071224_AA) JCL - 20071219_01 sysinfo - [C:/derbydev/trunk/test] java org.apache.derby.tools.sysinfo -- Java Information -- Java Version:1.6.0 Java Vendor: IBM Corporation Java home: c:\p4client\mkutty_main\ibm16\jre Java classpath: c:/derbydev/trunk/classes;c:/derbydev/trunk/tools/java/junit.ja r;. OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 2 Java user name: mkutty Java user home: C:\Documents and Settings\Administrator Java user dir: C:\derbydev\trunk\test java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [C:\derbydev\trunk\classes] 10.4.0.0 alpha - (1) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.4.0.0 alpha - (1) Found support for locale: [de_DE] version: 10.4.0.0 alpha - (1) Found support for locale: [es] version: 10.4.0.0 alpha - (1) Found support for locale: [fr] version: 10.4.0.0 alpha - (1) Found support for locale: [hu] version: 10.4.0.0 alpha - (1) Found support for locale: [it] version: 10.4.0.0 alpha - (1) Found support for locale: [ja_JP] version: 10.4.0.0 alpha - (1) Found support for locale: [ko_KR] version: 10.4.0.0 alpha - (1) Found support for locale: [pl] version: 10.4.0.0 alpha - (1) Found support for locale: [pt_BR] version: 10.4.0.0 alpha - (1) Found support for locale: [ru] version: 10.4.0.0 alpha - (1) Found support for locale: [zh_CN] version: 10.4.0.0 alpha - (1) Found support for locale: [zh_TW] version: 10.4.0.0 alpha - (1) -- Reporter: Manjula Kutty Assignee: Kathey Marsden Fix For: 10.4.0.0 Attachments: derby-3400_diff.txt, TestDerby3400.java I can reproduce the test with the just one old version(10.2.2.0) Here is the junit stack trace 1) testGetTypeInfo(org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest)junit.framework.AssertionFailedError: Column nullability do not match for column 16 expected:1 but was:0 at org.apache.derbyTesting.junit.JDBC.assertNullability(JDBC.java:741) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.assertMetaDataResultSet(DatabaseMetaDataTest.java:2348) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetTypeInfo(DatabaseMetaDataTest.java:2230) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at
[jira] Commented: (DERBY-3413) Derby crash in LockControl.isGrantable
[ https://issues.apache.org/jira/browse/DERBY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568640#action_12568640 ] Ludovic Pourrat commented on DERBY-3413: Both solutions will be tested on our pre produciton systems looking forward to bring them on production. I will give some comment and update on that issue within few days. Derby crash in LockControl.isGrantable -- Key: DERBY-3413 URL: https://issues.apache.org/jira/browse/DERBY-3413 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.3.1.4 Environment: Sun Solaris Sparc JVM 1.5.0-11 Reporter: Ludovic Pourrat Attachments: hs_err_pid23203.log The DERBY database server crashes sometimes on our production environment by producing a hs_err_pid file. After recycling our application the same process come throught. On the client side all the DERBY connections are loss. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2993) Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual
[ https://issues.apache.org/jira/browse/DERBY-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-2993: -- Derby Info: (was: [Patch Available]) Great! Thank you for your contribution. Committed revision 627532. Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual - Key: DERBY-2993 URL: https://issues.apache.org/jira/browse/DERBY-2993 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefjdbc77156.html Reporter: Tomohito Nakayama Assignee: Abhilash T.G Priority: Minor Attachments: DERBY-2993.diff In the table of JDBC 2.0 ResultSet Methods Supported, there exists two rows of beforeFirst(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2012) The Syntax of the UPDATE and DELETE statements is not correct in the reference manual
[ https://issues.apache.org/jira/browse/DERBY-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G updated DERBY-2012: Derby Info: [Patch Available] The Syntax of the UPDATE and DELETE statements is not correct in the reference manual - Key: DERBY-2012 URL: https://issues.apache.org/jira/browse/DERBY-2012 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Christian d'Heureuse Assignee: Abhilash T.G Priority: Minor Attachments: DERBY-2012.diff The syntax description of the UPDATE and DELETE statements in the reference manual does not imply that an alias name may be specified for the table name. The statements are currently documented as: UPDATE table-Name SET ... DELETE FROM table-Name [ WHERE ... ] This should be changed to: UPDATE table-Name [ [ AS ] correlation-Name ] SET ... DELETE FROM table-Name [ [ AS ] correlation-Name ] [ WHERE ... ] (Table alias names for UPDATE and DELETE are important for the WHERE clauses, e.g. when the same table is used a second time within a subquery in the WHERE condition, e.g.: UPDATE table1 a SET ... WHERE EXISTS ( SELECT * FROM table1 b WHERE a.field1 = b.field2 ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2012) The Syntax of the UPDATE and DELETE statements is not correct in the reference manual
[ https://issues.apache.org/jira/browse/DERBY-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G updated DERBY-2012: Attachment: DERBY-2012.diff I made changes to the following: rrefsqlj26498.dita rrefsqlj35981.dita The recommended changes have been made. The diff file and a zip file have been attached. The Syntax of the UPDATE and DELETE statements is not correct in the reference manual - Key: DERBY-2012 URL: https://issues.apache.org/jira/browse/DERBY-2012 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Christian d'Heureuse Assignee: Abhilash T.G Priority: Minor Attachments: DERBY-2012.diff The syntax description of the UPDATE and DELETE statements in the reference manual does not imply that an alias name may be specified for the table name. The statements are currently documented as: UPDATE table-Name SET ... DELETE FROM table-Name [ WHERE ... ] This should be changed to: UPDATE table-Name [ [ AS ] correlation-Name ] SET ... DELETE FROM table-Name [ [ AS ] correlation-Name ] [ WHERE ... ] (Table alias names for UPDATE and DELETE are important for the WHERE clauses, e.g. when the same table is used a second time within a subquery in the WHERE condition, e.g.: UPDATE table1 a SET ... WHERE EXISTS ( SELECT * FROM table1 b WHERE a.field1 = b.field2 ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1992) Upgrade to DITA Open Toolkit version 1.3
[ https://issues.apache.org/jira/browse/DERBY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568670#action_12568670 ] Michelle Caisse commented on DERBY-1992: I've successfully built a doc using DITA Open Toolkit 1.4.1. If nobody objects, I'd like to take this issue. Upgrade to DITA Open Toolkit version 1.3 Key: DERBY-1992 URL: https://issues.apache.org/jira/browse/DERBY-1992 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 11.0.0.0 Reporter: Laura Stewart Assignee: Laura Stewart Fix For: 11.0.0.0 There are major improvements in the DITA Open Toolkit, including improvements in the display of index entries. Derby is currently on version 1.1.2.1 and needs to upgrade to this new version of the DITA Open Toolkit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3310: -- I think the assert code is correctly testing for what it assumes to be true - ie. that class types of the sort template will exactly match subsequent rows fed to the sort. It may work without the assert in this case but I am not sure that will always be true. Basically the sort interface requires a template of what rows will look like when fed into the sort. So column[N] of each row fed into the sort should be the exact same type as template[N]. One could build a sorter that compared different types in the same column but I didn't think Derby currently required that. ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions -- Key: DERBY-3310 URL: https://issues.apache.org/jira/browse/DERBY-3310 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: cast-repro.sql The following code CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; gives ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568652#action_12568652 ] Dyre Tjeldvoll commented on DERBY-3404: --- Great. Fwiw, her is the call stack showing where the value is changed from Y to null: (dbx) where =[1] org.apache.derby.iapi.types.SQLChar.restoreToNull(this = OBJECT) SQLChar.java:838 [2] org.apache.derby.iapi.types.DataType.recycle(this = OBJECT) DataType.java:254 [3] org.apache.derby.impl.sql.execute.ValueRow.resetRowArray(this = OBJECT) ValueRow.java:179 [4] org.apache.derby.impl.sql.execute.ScanResultSet.close(this = OBJECT) ScanResultSet.java:237 [5] org.apache.derby.impl.sql.execute.TableScanResultSet.close(this = OBJECT) TableScanResultSet.java:796 [6] org.apache.derby.impl.sql.execute.BulkTableScanResultSet.close(this = OBJECT) BulkTableScanResultSet.java:348 [7] org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.endTransactionActivationHandling(this = OBJECT, forRollback = false) GenericLanguageConnectionContext.java:2766 [8] org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(this = OBJECT, commitStore = true, sync = true, commitflag = 0, requestedByUser = true) GenericLanguageConnectionContext.java:1125 [9] org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(this = OBJECT) GenericLanguageConnectionContext.java:1003 [10] org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(this = OBJECT) TransactionResourceImpl.java:237 [11] org.apache.derby.impl.jdbc.EmbedConnection.commit(this = OBJECT) EmbedConnection.java:1482 [12] CloseOnCommit.main(args = ARRAY) CloseOnCommit.java:14 (dbx) So I guess one of the calls to XResultSet.close() that were added in DERBY-827 is causing the regression (as you guessed) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-1824: -- Derby Info: [Patch Available] Permission/privlege names in exceptions should be in upper case as keywords, not lower case. Key: DERBY-1824 URL: https://issues.apache.org/jira/browse/DERBY-1824 Project: Derby Issue Type: Improvement Components: SQL Reporter: Daniel John Debrunner Assignee: Jazarine Jamal Priority: Minor Attachments: DERBY1824.diff E.g. ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table 'MAMTA2'.'V21VIEWTEST'. should be ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-1824: -- Attachment: DERBY1824.diff I made changes to java/engine/org/apache/derby/iapi/sql/dictionary/StatementTablePermission.java The diff file has been attached. Please have look. I am running the junit tests for this fix. Permission/privlege names in exceptions should be in upper case as keywords, not lower case. Key: DERBY-1824 URL: https://issues.apache.org/jira/browse/DERBY-1824 Project: Derby Issue Type: Improvement Components: SQL Reporter: Daniel John Debrunner Assignee: Jazarine Jamal Priority: Minor Attachments: DERBY1824.diff E.g. ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table 'MAMTA2'.'V21VIEWTEST'. should be ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568654#action_12568654 ] Jazarine Jamal commented on DERBY-1824: --- I built the project with the ccode change. Then, i reproduced the same error and the required change has been reflected. Permission/privlege names in exceptions should be in upper case as keywords, not lower case. Key: DERBY-1824 URL: https://issues.apache.org/jira/browse/DERBY-1824 Project: Derby Issue Type: Improvement Components: SQL Reporter: Daniel John Debrunner Assignee: Jazarine Jamal Priority: Minor Attachments: DERBY1824.diff E.g. ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table 'MAMTA2'.'V21VIEWTEST'. should be ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-151) Thread termination - XSDG after operation is 'complete'
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Sabatino updated DERBY-151: Attachment: Derby151Test.java Thread termination - XSDG after operation is 'complete' Key: DERBY-151 URL: https://issues.apache.org/jira/browse/DERBY-151 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.0.2.1 Environment: Linux kernel 2.4.21-243-athlon (SuSE 9.0) Reporter: Barnet Wagman Attachments: d151.java, derby.log, Derby151Test.java I've encountered what appears to be a bug related to threading. After an INSERT operation, if the invoking thread terminates too quickly, Derby throws an XSDG. The bug is a bit difficult to isolate but it occurs consistently in the following situation (with a particular database and an operation of a particular size): Derby is running in embedded mode with autocommit on. The application performs an INPUT operation from a thread that is not the main thread. The INPUT is issued using a PreparedStatement. The INPUT adds ~ 256 records of six fields each. (Note that INSERTs of this size seem to work fine in other contexts.) The preparedStatement.executeUpdate() seems to excute successfully; at least it returns without throwing an exception. The thread that invoked the INPUT operation then terminates (but NOT the application). The next INPUT operation then results in an ERROR XSDG1: Page Page(7,Container(0, 1344)) could not be written to disk, please check if disk is full. The disk is definitely not full. HOWEVER, if I put the calling thread to sleep for a second before it exits, the problem does not occur. I'm not quite sure what to make of this. I was under the impression that most of Derby's activity occurs in the application's threads. Could Derby be creating a child thread from in the application thread, which dies when the parent thread terminates? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-151) Thread termination - XSDG after operation is 'complete'
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568662#action_12568662 ] Paul Sabatino commented on DERBY-151: - I thought I'd add a little more clarification to this. This error seems to only come up when the interrupt flag is set on a thread that is doing a commit that which causes a page to be written to disk. I figured this out by modifying the d151.java to take pageSize as an argument and to count how many iterations of insert and interrupt it took to fail. I then varied the pageSize and noted that the number of iterations before failure was proportional to the pageSize. So my guess was that the page was being written somewhere under the covers and causing this error. I've attached my test program. I hope this helps resolve this issue. Thread termination - XSDG after operation is 'complete' Key: DERBY-151 URL: https://issues.apache.org/jira/browse/DERBY-151 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.0.2.1 Environment: Linux kernel 2.4.21-243-athlon (SuSE 9.0) Reporter: Barnet Wagman Attachments: d151.java, derby.log, Derby151Test.java I've encountered what appears to be a bug related to threading. After an INSERT operation, if the invoking thread terminates too quickly, Derby throws an XSDG. The bug is a bit difficult to isolate but it occurs consistently in the following situation (with a particular database and an operation of a particular size): Derby is running in embedded mode with autocommit on. The application performs an INPUT operation from a thread that is not the main thread. The INPUT is issued using a PreparedStatement. The INPUT adds ~ 256 records of six fields each. (Note that INSERTs of this size seem to work fine in other contexts.) The preparedStatement.executeUpdate() seems to excute successfully; at least it returns without throwing an exception. The thread that invoked the INPUT operation then terminates (but NOT the application). The next INPUT operation then results in an ERROR XSDG1: Page Page(7,Container(0, 1344)) could not be written to disk, please check if disk is full. The disk is definitely not full. HOWEVER, if I put the calling thread to sleep for a second before it exits, the problem does not occur. I'm not quite sure what to make of this. I was under the impression that most of Derby's activity occurs in the application's threads. Could Derby be creating a child thread from in the application thread, which dies when the parent thread terminates? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568679#action_12568679 ] Kathey Marsden commented on DERBY-3310: --- I think then we get back to my question of whether both template and row data should be SQLInteger or both should be SQLLongint at the time of the sort. BTW this is the trace from the point where we now change the type of the sourceColumn from INTEGER NOT NULL to BIGINT. I think I need to better understand the VirtualColumnNode change and why it was made. Thread [main] (Suspended (breakpoint at line 284 in VirtualColumnNode)) VirtualColumnNode.setType(DataTypeDescriptor) line: 284 ResultColumnList.copyTypesAndLengthsToSource(ResultColumnList) line: 1645 InsertNode.bindStatement() line: 426 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 314 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 88 GenericLanguageConnectionContext.prepareInternalStatement(SchemaDescriptor, String, boolean, boolean) line: 768 EmbedStatement40(EmbedStatement).execute(String, boolean, boolean, int, int[], String[]) line: 607 EmbedStatement40(EmbedStatement).execute(String) line: 556 ij.executeImmediate(String) line: 330 utilMain.doCatch(String) line: 508 utilMain.runScriptGuts() line: 350 utilMain.go(LocalizedInput[], LocalizedOutput, Properties) line: 248 Main.go(LocalizedInput, LocalizedOutput, Properties) line: 215 Main.mainCore(String[], Main) line: 181 Main.main(String[]) line: 73 ij.main(String[]) line: 59 ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions -- Key: DERBY-3310 URL: https://issues.apache.org/jira/browse/DERBY-3310 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: cast-repro.sql The following code CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; gives ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-3409: - Derby Info: [Patch Available] Remove JDBC 2.0-specific topics from Reference Manual and merge implementation notes as needed -- Key: DERBY-3409 URL: https://issues.apache.org/jira/browse/DERBY-3409 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.3.2.1 Reporter: Kim Haase Assignee: Kim Haase Priority: Minor Attachments: DERBY-3409.diff, DERBY-3409.stat, DERBY-3409.zip The following files should be removed and their contents merged, where appropriate, with the main files for the interfaces concerned: JDBC 2.0 features (rrefjdbc2_0summary.dita): remove java.sql.CallableStatement interface: supported JDBC 2.0 methods (rrefjdbc52637.dita): remove java.sql.Connection interface: supported JDBC 2.0 methods (rrefjdbc80004.dita): remove? It appears that the implementation notes are no longer valid. They state that ResultSet.TYPE_SCROLL_SENSITIVE is not supported and that if you specify it, Derby issues an SQLWarning. However, I tried this and no warning seemed to be issued. java.sql.DatabaseMetaData interface: supported JDBC 2.0 methods (rrefjdbc66688.dita): remove java.sql.PreparedStatement interface: supported JDBC 2.0 methods (rrefjdbc99392.dita): remove java.sql.ResultSet interface: supported JDBC 2.0 methods (rrefjdbc77156.dita): remove, after adding implementation notes to the topic java.sql.ResultSet interface (http://db.apache.org/derby/docs/dev/ref/rrefjdbc23502.html), assuming they are still valid. (Removing this file will allow us to resolve DERBY-2993, Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual.) java.sql.ResultSetMetaData interface: supported JDBC 2.0 methods (rrefjdbc71949.dita) java.sql.Statement interface: supported JDBC 2.0 methods (rrefjdbc59162.dita): if implementation notes are still valid, change title to java.sql.Statement interface, move topic to the general JDBC reference section, remove table, and provide one-sentence implementation notes on the appropriate methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1400) Cleanup code in network server's DRDAStatement class
[ https://issues.apache.org/jira/browse/DERBY-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-1400: -- Derby Info: (was: [Patch Available]) Let's see if I can manage to uncheck the box this time... Cleanup code in network server's DRDAStatement class Key: DERBY-1400 URL: https://issues.apache.org/jira/browse/DERBY-1400 Project: Derby Issue Type: Improvement Components: Network Server, Newcomer Affects Versions: 10.1.3.1, 10.2.1.6 Reporter: Deepa Remesh Assignee: Abhilash T.G Priority: Trivial Attachments: DERBY-1400.diff The following cleanup tasks were identified as part of DERBY-1002 (http://issues.apache.org/jira/browse/DERBY-1002): * pkgcnstkn, pkgid, pkgsn variables can be removed from DRDAStatement since these are derived from pkgnamcsn object. * Look into what is required by initialize() of default statement. Currently, initialize just calls setTypDefValues(). Once the purpose of this method is confirmed, we may need to modify the comments at places it is currently called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Release schedule for 10.3.2.2
I'm was interested in finding out when the next patch 10.3.2.2 will be released. Any projections? Thanks, Scott
[jira] Updated: (DERBY-2012) The Syntax of the UPDATE and DELETE statements is not correct in the reference manual
[ https://issues.apache.org/jira/browse/DERBY-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-2012: -- Derby Info: (was: [Patch Available]) Thanks! Committed revision 627566. The Syntax of the UPDATE and DELETE statements is not correct in the reference manual - Key: DERBY-2012 URL: https://issues.apache.org/jira/browse/DERBY-2012 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Christian d'Heureuse Assignee: Abhilash T.G Priority: Minor Attachments: DERBY-2012.diff The syntax description of the UPDATE and DELETE statements in the reference manual does not imply that an alias name may be specified for the table name. The statements are currently documented as: UPDATE table-Name SET ... DELETE FROM table-Name [ WHERE ... ] This should be changed to: UPDATE table-Name [ [ AS ] correlation-Name ] SET ... DELETE FROM table-Name [ [ AS ] correlation-Name ] [ WHERE ... ] (Table alias names for UPDATE and DELETE are important for the WHERE clauses, e.g. when the same table is used a second time within a subquery in the WHERE condition, e.g.: UPDATE table1 a SET ... WHERE EXISTS ( SELECT * FROM table1 b WHERE a.field1 = b.field2 ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY
Hi I would like to know if SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY in SystemProcedures.java is used only only when issuing a VALUES SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY() function call? If not, when is it otherwise executed? Just give one eg. if possible. I am working on a bug and the answer to this query will be very helpfull. Thanks..
[jira] Commented: (DERBY-3105) No documentation of ij -ca option
[ https://issues.apache.org/jira/browse/DERBY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568686#action_12568686 ] Kim Haase commented on DERBY-3105: -- It would be helpful to know, before someone modifies the documentation, whether there is some reason why the -ca option was not documented. Is it actually implemented? Is the ij documentation incorrect, or is it the command line usage statement that needs to be fixed? Thank you. No documentation of ij -ca option - Key: DERBY-3105 URL: https://issues.apache.org/jira/browse/DERBY-3105 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.1.4 Reporter: Sebb Assignee: Abhilash T.G Priority: Minor The ij tool gives the following help output: Usage: java org.apache.derby.tools.ij [-p propertyfile] [-ca connectionAttributePropertyFile] [inputfile] The -p flag and inputfile are documented in derbytools.pdf, but the -ca flag does not seem to be documented anywhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2320) Example in DEGREES function is not appropriate.
[ https://issues.apache.org/jira/browse/DERBY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568692#action_12568692 ] Kim Haase commented on DERBY-2320: -- Looks good! Thanks! Example in DEGREES function is not appropriate. Key: DERBY-2320 URL: https://issues.apache.org/jira/browse/DERBY-2320 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rreffuncdegrees.html Reporter: Tomohito Nakayama Assignee: Abhishek Bhaskaran Priority: Minor Attachments: DERBY-2320.diff, rreffuncdegrees.dita, rreffuncdegrees.html In the description of DEGREES function in Derby Reference Manual, next description exists. Attention: The conversion from radians to degrees is not exact. You should not expect that the COS(RADIANS(90.0)) to exactly equal 0.0. Because the page is for DEGREES function , example here should be DEGREES( ACOS( 0 ) ) and 90.0 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2913) Derby Eclipse ui plugin should make possible to switch networkserver to -noSecurityManager, or change to a user specified policy file for network server; doc plugin should
[ https://issues.apache.org/jira/browse/DERBY-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjula Kutty updated DERBY-2913: - Attachment: DERBY-2913_02_13_diff.txt DERBY-2913_02_13_stat.txt I'm attaching a partial patch for this enhancement. I may work with this again at a later time. So thought before loosing this I should secure it some where. Please do not try this patch now, it has the gui but no actions yet. So this patch is not ready for review Derby Eclipse ui plugin should make possible to switch networkserver to -noSecurityManager, or change to a user specified policy file for network server; doc plugin should document this - Key: DERBY-2913 URL: https://issues.apache.org/jira/browse/DERBY-2913 Project: Derby Issue Type: Improvement Components: Eclipse Plug-in Affects Versions: 10.3.1.4, 10.4.0.0 Environment: eclipse 3.2.1, at least, derby 10.3 and up Reporter: Myrna van Lunteren Attachments: DERBY-2913_02_13_diff.txt, DERBY-2913_02_13_stat.txt As of Derby 10.3, the network server by default starts with a security manager. The derby eclipse plugins do not enable a user to configure this. It should be possible to choose between setting a different policy file, or switching to start without securityManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-3409: - Attachment: DERBY-3409.stat DERBY-3409.zip DERBY-3409.diff Attaching a patch, DERBY-3409.diff, that removes the 8 JDBC 2.0 topics and modifies three more topics, by moving implementation-specific material into them. I would be very grateful if someone familiar with our current JDBC implementation would review the three modified topics to determine whether the implementation-specific material is still correct as of JDBC 3 and 4. The modified topics are in DERBY-3409.zip. D src/ref/rrefjdbc99392.dita D src/ref/rrefjdbc2_0summary.dita D src/ref/rrefjdbc66688.dita D src/ref/rrefjdbc59162.dita D src/ref/rrefjdbc77156.dita D src/ref/rrefjdbc71949.dita D src/ref/rrefjdbc80004.dita D src/ref/rrefjdbc52637.dita M src/ref/refderby.ditamap M src/ref/rrefjdbc40794.dita M src/ref/rrefjdbc96386.dita M src/ref/rrefjdbc23502.dita Remove JDBC 2.0-specific topics from Reference Manual and merge implementation notes as needed -- Key: DERBY-3409 URL: https://issues.apache.org/jira/browse/DERBY-3409 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.3.2.1 Reporter: Kim Haase Assignee: Kim Haase Priority: Minor Attachments: DERBY-3409.diff, DERBY-3409.stat, DERBY-3409.zip The following files should be removed and their contents merged, where appropriate, with the main files for the interfaces concerned: JDBC 2.0 features (rrefjdbc2_0summary.dita): remove java.sql.CallableStatement interface: supported JDBC 2.0 methods (rrefjdbc52637.dita): remove java.sql.Connection interface: supported JDBC 2.0 methods (rrefjdbc80004.dita): remove? It appears that the implementation notes are no longer valid. They state that ResultSet.TYPE_SCROLL_SENSITIVE is not supported and that if you specify it, Derby issues an SQLWarning. However, I tried this and no warning seemed to be issued. java.sql.DatabaseMetaData interface: supported JDBC 2.0 methods (rrefjdbc66688.dita): remove java.sql.PreparedStatement interface: supported JDBC 2.0 methods (rrefjdbc99392.dita): remove java.sql.ResultSet interface: supported JDBC 2.0 methods (rrefjdbc77156.dita): remove, after adding implementation notes to the topic java.sql.ResultSet interface (http://db.apache.org/derby/docs/dev/ref/rrefjdbc23502.html), assuming they are still valid. (Removing this file will allow us to resolve DERBY-2993, Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual.) java.sql.ResultSetMetaData interface: supported JDBC 2.0 methods (rrefjdbc71949.dita) java.sql.Statement interface: supported JDBC 2.0 methods (rrefjdbc59162.dita): if implementation notes are still valid, change title to java.sql.Statement interface, move topic to the general JDBC reference section, remove table, and provide one-sentence implementation notes on the appropriate methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1992) Upgrade to DITA Open Toolkit version 1.3
[ https://issues.apache.org/jira/browse/DERBY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568693#action_12568693 ] Kim Haase commented on DERBY-1992: -- It would be wonderful if we could get a toolkit that improves the output for PDF and the one-file HTML in particular. I hope it doesn't need too much customizing for our needs. Thanks for taking this on. (Whether it works out for 10.4 or later.) Upgrade to DITA Open Toolkit version 1.3 Key: DERBY-1992 URL: https://issues.apache.org/jira/browse/DERBY-1992 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 11.0.0.0 Reporter: Laura Stewart Assignee: Laura Stewart Fix For: 11.0.0.0 There are major improvements in the DITA Open Toolkit, including improvements in the display of index entries. Derby is currently on version 1.1.2.1 and needs to upgrade to this new version of the DITA Open Toolkit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Release schedule for 10.3.2.2
Scott Alexander wrote: I'm was interested in finding out when the next patch 10.3.2.2 will be released. Any projections? Thanks, Scott Hi Scott, No-one has volunteered to produce another patch on the 10.3 branch. Someone has volunteered to produce a new (10.4) feature release soon: http://wiki.apache.org/db-derby/DerbyTenFourRelease Hope this helps, -Rick
Re: SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY
Jazarine Jamal wrote: Hi I would like to know if SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY in SystemProcedures.java is used only only when issuing a VALUES SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY() function call? If not, when is it otherwise executed? Just give one eg. if possible. I am working on a bug and the answer to this query will be very helpfull. Thanks.. Hi Jazarine, I don't know if this is what you are looking for, but here is an example of invoking get_database_property in a query: create function intToString ( intVal int ) returns varchar( 10 ) language java parameter style java no sql external name 'java.lang.Integer.toString' ; select t2.* from sys.systables systabs, table (syscs_diag.space_table(systabs.tablename)) as t2 where systabs.tabletype = 'T' and intToString( t2.pagesize )=syscs_util.syscs_get_database_property( 'derby.storage.pageSize' ) ; Hope this helps, -Rick
[jira] Updated: (DERBY-3321) NullPointerException for 'NOT EXISTS' with nested subquery
[ https://issues.apache.org/jira/browse/DERBY-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3321: -- Affects Version/s: 10.0.2.1 10.1.3.1 10.2.2.0 Verified this back to 10.0.2.1 so it's not a regression. Below is the full stack trace. (select bb from (select bb from b) p where a.bb=p.bb); ERROR XJ001: Java exception: ': java.lang.NullPointerException'. java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:245) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1946) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:613) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:556) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:330) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:353) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248) at org.apache.derby.impl.tools.ij.Main.go(Main.java:215) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181) at org.apache.derby.impl.tools.ij.Main.main(Main.java:73) at org.apache.derby.tools.ij.main(ij.java:59) Caused by: java.lang.NullPointerException at org.apache.derby.impl.sql.compile.FromSubquery.getMatchingColumn(FromSubquery.java:289) at org.apache.derby.impl.sql.compile.FromList.bindColumnReference(FromList.java:602) at org.apache.derby.impl.sql.compile.ColumnReference.bindExpression(ColumnReference.java:349) at org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(ResultColumn.java:552) at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(ResultColumnList.java:680) at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:445) at org.apache.derby.impl.sql.compile.SelectNode.bindTargetExpressions(SelectNode.java:597) at org.apache.derby.impl.sql.compile.SubqueryNode.bindExpression(SubqueryNode.java:483) at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindOperand(UnaryOperatorNode.java:333) at org.apache.derby.impl.sql.compile.UnaryLogicalOperatorNode.bindExpression(UnaryLogicalOperatorNode.java:74) at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:468) at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:227) at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java:140) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(CursorNode.java:236) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:314) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConne ctionContext.java:768) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:607) ... 9 more NullPointerException for 'NOT EXISTS' with nested subquery -- Key: DERBY-3321 URL: https://issues.apache.org/jira/browse/DERBY-3321 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.1, 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0 Reporter: Jørgen Løland Priority: Minor Attachments: derby.log Queries with 'not exists' followed by a nested subquery results in NPE: ---8-- connect 'jdbc:derby:testdb;create=true'; create table a (aa int, bb int); -- 0 rows inserted/updated/deleted create table b (bb int); -- 0 rows inserted/updated/deleted insert into a values (1, 1), (1, 2), (2, 2); -- 3 rows inserted/updated/deleted insert into b values (1); -- 1 row inserted/updated/deleted select * from a where not exists (select bb from b where a.bb=b.bb); -- AA |BB -- -- -- 1 |2 -- 2 |2 select bb from (select bb from b) p; -- BB -- ---
junit license
I just downloaded junit 4.4. It comes with a BSD license. I notice that we don't check junit.jar into our codeline however. Is the BSD license incompatible with Apache 2.0? I am not a lawyer, but it seems that we would satisfy the conditions of the junit license if we included a copyright notice and disclaimer in our NOTICE file. Other opinions? Thanks, -Rick
[jira] Commented: (DERBY-3105) No documentation of ij -ca option
[ https://issues.apache.org/jira/browse/DERBY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568744#action_12568744 ] Kathey Marsden commented on DERBY-3105: --- A little bit of ancient history on this. The -ca option was introduced to be able to pass JCC attributes and Cloudscape attributes in ij. It used to be that you could not specify both client and embedded attributes in the JCC url. I think the -ca option doesn't really add value and should be deprecated (removed from the usage message) and not documented. No documentation of ij -ca option - Key: DERBY-3105 URL: https://issues.apache.org/jira/browse/DERBY-3105 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.1.4 Reporter: Sebb Assignee: Abhilash T.G Priority: Minor The ij tool gives the following help output: Usage: java org.apache.derby.tools.ij [-p propertyfile] [-ca connectionAttributePropertyFile] [inputfile] The -p flag and inputfile are documented in derbytools.pdf, but the -ca flag does not seem to be documented anywhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3412) junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError
[ https://issues.apache.org/jira/browse/DERBY-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3412: -- is this test failing here because it is running in a different order than other jvm's so that issue may be in other tests, or is this test wrong? Here are the changes that happened when this issue started to appear, have not narrowed down to one change: SUBVERSION LOG FROM 620381 TO 620689: r620522 | oysteing | 2008-02-11 08:38:11 -0800 (Mon, 11 Feb 2008) | 4 lines DERBY-3392: Performing failover on a database not being replicated should give a more meaningful error message. Contributed by Narayanan. r620499 | oysteing | 2008-02-11 06:54:39 -0800 (Mon, 11 Feb 2008) | 3 lines DERBY-3359: Make mf final and some other minor clean-up. r620485 | kristwaa | 2008-02-11 05:53:32 -0800 (Mon, 11 Feb 2008) | 4 lines DERBY-3309: Minor cleanups in ClientPooledConnection40 and ClientPooledConnection. This patch fixes the broken synchronization of the list of connection event listeners, and also replaces the Vector with an ArrayList. Patch file: derby-3309-4a-cpc_listeners_synch.diff r620483 | oysteing | 2008-02-11 05:14:08 -0800 (Mon, 11 Feb 2008) | 3 lines DERBY-3359: Make sure to initialize mf in constructor. Contributed by Narayanan. r620480 | kristwaa | 2008-02-11 05:02:38 -0800 (Mon, 11 Feb 2008) | 3 lines DERBY-3306: jdbc4.StatementEventsTest cannot be run individually in a clean environment. This is in fact a more general fix for tests using a DataSource obtained through the JUnit framework utility classes to create connections. The connections will now default to create the database if it does not exists. The accompanying test changes were required to get a clean suites.All run, and falls into three categories; test doesn't want to create db, asserting on zero warnings or uses connection attributes that conflict with db creation. Patch file: derby-3306-1c-create_db_by_default_and_test_fixes.diff r620469 | kristwaa | 2008-02-11 04:14:17 -0800 (Mon, 11 Feb 2008) | 3 lines Removed unused, private field 'accumulatedSetReadOnlyWarning_'. Patch file: n/a r620453 | oysteing | 2008-02-11 02:53:18 -0800 (Mon, 11 Feb 2008) | 3 lines DERBY-3359: Replication dynamically adjust shipping interval for LogShipper. Contributed by Narayanan. r620444 | oysteing | 2008-02-11 01:31:20 -0800 (Mon, 11 Feb 2008) | 4 lines DERBY-3383: Replication: Make sure stopSlave does not boot the database if not already booted. Contributed by Jorgen Loland junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError -- Key: DERBY-3412 URL: https://issues.apache.org/jira/browse/DERBY-3412 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: Java Version:J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: c:\jartest\weme6.1 Java classpath: c:/jartest/classes/derby.jar;c:/jartest/classes/derbyLocale_zh_TW.jar;c:/jartest/classes/derbyLocale_zh_CN.jar;c:/jartest/classes/derbyLocale_ru.jar;c:/jartest/classes/derbyLocale_pt_BR.jar;c:/jartest/classes/derbyLocale_pl.jar;c:/jartest/classes/derbyLocale_ko_KR.jar;c:/jartest/classes/derbyLocale_ja_JP.jar;c:/jartest/classes/derbyLocale_it.jar;c:/jartest/classes/derbyLocale_hu.jar;c:/jartest/classes/derbyLocale_fr.jar;c:/jartest/classes/derbyLocale_es.jar;c:/jartest/classes/derbyLocale_de_DE.jar;c:/jartest/classes/derbyLocale_cs.jar;c:/jartest/tools/java/junit.jar;c:/jartest/classes/derbytools.jar;c:/jartest/classes/derbyrun.jar;c:/jartest/classes/derbyTesting.jar;c:/jartest/classes/functionTests.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 2 Java user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\jartest\JarResults.2008-02-11\weme6.1_derbyall java.specification.name: J2ME Foundation
[jira] Updated: (DERBY-3412) junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError
[ https://issues.apache.org/jira/browse/DERBY-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3412: -- The test failed again in the same environment. Here is the output with the added failure information printed from dan's change: There were 5 failures: 1) testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError: Expected no SQLWarnings - got: 01J01 Database 'wombat' not created, connection made to existing database instead. at org.apache.derbyTesting.junit.JDBC.assertNoWarnings(JDBC.java:521) at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testForwardOnlyNegative(ScrollCursors2Test.java:90) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testForwardOnlyPositive(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError: Expected no SQLWarnings - got: 01J01 Database 'wombat' not created, connection made to existing database instead. at org.apache.derbyTesting.junit.JDBC.assertNoWarnings(JDBC.java:521) at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testForwardOnlyPositive(ScrollCursors2Test.java:252) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 3) testScrollInsensitivePositive(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError: Expected no SQLWarnings - got: 01J01 Database 'wombat' not created, connection made to existing database instead. at org.apache.derbyTesting.junit.JDBC.assertNoWarnings(JDBC.java:521) at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testScrollInsensitivePositive(ScrollCursors2Test.java:337) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 4) testScrollInsensitiveNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError: Expected no SQLWarnings - got: 01J01 Database 'wombat' not created, connection made to existing database instead. at org.apache.derbyTesting.junit.JDBC.assertNoWarnings(JDBC.java:521) at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testScrollInsensitiveNegative(ScrollCursors2Test.java:486) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 5) testCallableStatements(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.ComparisonFailure: expected:...2 but was:...1 at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testCallableStatements(ScrollCursors2Test.java:561) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at
Re: junit license
Rick Hillegas wrote: I just downloaded junit 4.4. It comes with a BSD license. I notice that we don't check junit.jar into our codeline however. Is the BSD license incompatible with Apache 2.0? I am not a lawyer, but it seems that we would satisfy the conditions of the junit license if we included a copyright notice and disclaimer in our NOTICE file. The project web-site says CPL. http://sourceforge.net/projects/junit/ Could the BSD licence be for some BSD code included by junit? Dan.
[jira] Commented: (DERBY-3412) junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedErro
[ https://issues.apache.org/jira/browse/DERBY-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568757#action_12568757 ] Daniel John Debrunner commented on DERBY-3412: -- I would guess it is: 620480 | kristwaa | 2008-02-11 05:02:38 -0800 (Mon, 11 Feb 2008) | 3 lines ... The connections will now default to create the database if it does not exists. ... I thought that previously the getConnection() was smart enough to only set create if it was needed. Not sure why it needed to be changed. junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError -- Key: DERBY-3412 URL: https://issues.apache.org/jira/browse/DERBY-3412 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: Java Version:J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: c:\jartest\weme6.1 Java classpath: c:/jartest/classes/derby.jar;c:/jartest/classes/derbyLocale_zh_TW.jar;c:/jartest/classes/derbyLocale_zh_CN.jar;c:/jartest/classes/derbyLocale_ru.jar;c:/jartest/classes/derbyLocale_pt_BR.jar;c:/jartest/classes/derbyLocale_pl.jar;c:/jartest/classes/derbyLocale_ko_KR.jar;c:/jartest/classes/derbyLocale_ja_JP.jar;c:/jartest/classes/derbyLocale_it.jar;c:/jartest/classes/derbyLocale_hu.jar;c:/jartest/classes/derbyLocale_fr.jar;c:/jartest/classes/derbyLocale_es.jar;c:/jartest/classes/derbyLocale_de_DE.jar;c:/jartest/classes/derbyLocale_cs.jar;c:/jartest/tools/java/junit.jar;c:/jartest/classes/derbytools.jar;c:/jartest/classes/derbyrun.jar;c:/jartest/classes/derbyTesting.jar;c:/jartest/classes/functionTests.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 2 Java user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\jartest\JarResults.2008-02-11\weme6.1_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 Reporter: Mike Matrigali 5 new failures as of 2/11/08 in the ScrollCursors2Test, only seen in j2me test: 1) testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testForwardOnlyNegative(ScrollCursors2Test.java:95) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testForwardOnlyPositive(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testForwardOnlyPositive(ScrollCursors2Test.java:263) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 3) testScrollInsensitivePositive(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testScrollInsensitivePositive(ScrollCursors2Test.java:352) 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:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 4) testScrollInsensitiveNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at
[jira] Assigned: (DERBY-1671) Include junit.jar in Derby's svn to ease getting started for developers once ASF third-party licencing policy has been approved.
[ https://issues.apache.org/jira/browse/DERBY-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre reassigned DERBY-1671: -- Assignee: (was: Andrew McIntyre) Include junit.jar in Derby's svn to ease getting started for developers once ASF third-party licencing policy has been approved. Key: DERBY-1671 URL: https://issues.apache.org/jira/browse/DERBY-1671 Project: Derby Issue Type: Task Components: Build tools Reporter: Daniel John Debrunner Attachments: derby-1671-v1.diff *Draft* policy here indicates that CPL binaries can be added to Apache's SVN. http://people.apache.org/~cliffs/3party.html This is linked (redirected from) http://www.apache.org/legal/3party.html Need to check JUNit 3.8 is CPL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1992) Upgrade to DITA Open Toolkit version 1.3
[ https://issues.apache.org/jira/browse/DERBY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568771#action_12568771 ] Michelle Caisse commented on DERBY-1992: Unfortunately, I've hit a dead end on this issue due to licensing problems. Upgrading to DITA-OT 1.4.1 would not provide indexes because (1) indexes are not available for XHTML docs and (2) the PDF index generation depends on software that, though it has a free personal license, that license is not consistent with use within Apache (or any other organization, for that matter.) (Andrew mentioned this problem in email to derby-dev on 16 Nov 07.) Laura raised the issue of indexing support on the DITA Help forum (http://sourceforge.net/forum/message.php?msg_id=4127959) and by my reading of the response, getting a solution with a reasonable license doesn't look promising. DITA 1.4.1 does come with an Apache license. There is no longer a separate download for an Apache licensed toolkit. I haven't yet succeeded in creating pdf with 1.4.1. If there is any reason to upgrade given that we will not get indexes, I can pursue this. Upgrade to DITA Open Toolkit version 1.3 Key: DERBY-1992 URL: https://issues.apache.org/jira/browse/DERBY-1992 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 11.0.0.0 Reporter: Laura Stewart Assignee: Laura Stewart Fix For: 11.0.0.0 There are major improvements in the DITA Open Toolkit, including improvements in the display of index entries. Derby is currently on version 1.1.2.1 and needs to upgrade to this new version of the DITA Open Toolkit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: junit license
On Feb 13, 2008 2:45 PM, Rick Hillegas [EMAIL PROTECTED] wrote: I just downloaded junit 4.4. It comes with a BSD license. I notice that we don't check junit.jar into our codeline however. Is the BSD license incompatible with Apache 2.0? I am not a lawyer, but it seems that we would satisfy the conditions of the junit license if we included a copyright notice and disclaimer in our NOTICE file. Other opinions? If we don't redistribute it in any of our release artifacts, I don't believe there's a need to add any notice. There are plenty of examples of other projects that have checked junit.jar into the repository, and do not give notice in their NOTICES file. See, e.g.: http://svn.apache.org/repos/asf/xerces/java/trunk/tools/ http://svn.apache.org/repos/asf/lenya/trunk/lib/ and notice in Xerces's case that they include the license along the jar. If you plan on checking it in, there's a JIRA for it: http://issues.apache.org/jira/browse/DERBY-1671 I was going to do it, but then abandoned it after somebody expressed concern about JUnit 3.8.2 not working in some environment and figured I would continue to leave it up to individuals to get the right one for their environment. I don't remember offhand what the issue was, but it's probably better in the long run to go ahead and check in a version that works for most people. Just make sure it is properly excluded from the release distributions. Thanks, Andrew
[jira] Commented: (DERBY-3303) ArrayIndexOutOfBoundsException at MergeSort.compare
[
https://issues.apache.org/jira/browse/DERBY-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568780#action_12568780
]
A B commented on DERBY-3303:
A simpler way to reproduce the problem on trunk:
create table t1 (i int, j int, k int);
insert into t1 values (1, 1, 2), (1, 3, 3), (2, 3, 1), (2, 2, 4);
-- Works.
select sum(k) as s from t1 group by i order by 1;
-- Works.
select sum(k) as s from t1 group by i order by s;
-- Fails (ArrayIndexOutOfBounds / ASSERT); should fail with ERROR 42X77...
select sum(k) as s from t1 group by i order by 2;
-- Fails (ArrayIndexOutOfBounds / ASSERT)
select sum(k) as s from t1 group by i order by abs(1);
-- Fails (ArrayIndexOutOfBounds / ASSERT)
select sum(k) as s from t1 group by i order by sum(k);
ArrayIndexOutOfBoundsException at MergeSort.compare
---
Key: DERBY-3303
URL: https://issues.apache.org/jira/browse/DERBY-3303
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.2.1
Environment: -- Java Information --
Java Version:1.6.0_03
Java Vendor: Sun Microsystems Inc.
Java home: D:\Programs\Java\jre1.6.0_03
Java classpath: derbytools.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: Donatas
Java user home: C:\Documents and Settings\Donatas
Java user dir: d:\java\derby-10.3.2.1\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[D:\java\derby-10.3.2.1\lib\derbytools.jar] 10.3.2.1 - (599110)
--
- Locale Information -
--
Reporter: Donatas Ciuksys
Priority: Blocker
Attachments: db.zip, ddl.sql
Derby throws ArrayIndexOutOfBoundsException when I try to execute SQL query
shown below.
This is a regression, since Derby 10.2.2.0 executes this query without
problems.
Attached are DDL statements to create DB tables, and database itself (with
data).
2008-01-08 12:32:34.461 GMT Thread[DRDAConnThread_5,6,derby.daemons] (XID =
1497), (SESSIONID = 0), (DATABASE = InventorizacijaDB), (DRDAID =
NF01.G46A-666250070078662256{1}), Failed Statement is: select
MAX(preke0_.BARKODAS) as col_0_0_, MAX(preke0_.PAVADINIMAS) as col_1_0_,
MAX(preke0_.KIEKIS) as col_2_0_, SUM(irasas1_.FAKTINIS_KIEKIS) as col_3_0_
from PREKE preke0_, IRASAS irasas1_, IRASU_BLOKAS irasubloka2_ where
irasas1_.IRASU_BLOKAS=irasubloka2_.ID and
preke0_.UNIKALUS_KODAS=irasas1_.UNIKALUS_KODAS and
irasubloka2_.INVENTORIZACIJA=? group by irasas1_.UNIKALUS_KODAS order by
abs(SUM(irasas1_.FAKTINIS_KIEKIS)-MAX(preke0_.KIEKIS)) DESC with 1 parameters
begin parameter #1: 1 :end parameter
java.lang.ArrayIndexOutOfBoundsException: 5
at org.apache.derby.impl.store.access.sort.MergeSort.compare(Unknown
Source)
at org.apache.derby.impl.store.access.sort.SortBuffer.insert(Unknown
Source)
at org.apache.derby.impl.store.access.sort.MergeInserter.insert(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
