Regression Test Report - tinderbox_trunk16 554824 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 554824/2007-07-10 06:42:18 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 3301298 089.48% derbyall 083758375 0 1843.02% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-554824.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/554824_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/554824.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Re: Optimization test result
Hi Manjula, looks interesting. How have you produced those results? Is that optimizer test already part of derby or attached somewhere in JIRA? If not, can you share that code? I would like to do some experiments with optimizer and this might help me a lot. Thanks Julo Manjula Kutty wrote: Hi, I had run the optimization test and am attaching the report with 10.3 beta. Looks like 10.3 performs better than 10.2 in query optimization. Please have a look -- Thanks, Manjula.
[jira] Updated: (DERBY-2872) Add Replication functionality to Derby
[ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-2872: - Attachment: replication_funcspec_v3.html Attached new functional specification that incorporate the last few days of comments from Rick and Narayanan. Add Replication functionality to Derby -- Key: DERBY-2872 URL: https://issues.apache.org/jira/browse/DERBY-2872 Project: Derby Issue Type: New Feature Components: Miscellaneous Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: 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_script.txt 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.
Re: what is the right way to fix the import/export security issues (DERBY-2436, DERBY-2437)?
Bryan Pendleton wrote: 1) try to code access privileges in the routines themselves, that is separate from java security manager. Basically disallow access to derby files by adding code logic to determine if the files being read/written are derby files. Instead of trying to write this negative logic, figuring out what files *oughtn't* to be written to, perhaps it would be easier to specify things the other way, and change import/export so that they are only capable of reading-from/writing-to a new, well-known location, which is certain not to contain any other files of importance. That is, for each database, we define a new import/export scratch space, whose location defaults to something reasonable but can be configured on a database-by-database basis if necessary, and import only ever looks for files in that directory, and export only ever writes files to that directory. I had the same thoughts as you, Bryan, but I guess this will introduce incompatibilities for existing users who currently gets to decide where the exported data should be written. -- Øystein
Re: State of Derby at OSCON
What else are people planning to do for the next feature release? I am planning to work on support for duplicate nulls in unique index. https://issues.apache.org/jira/browse/DERBY-2212 thanks anurag
[jira] Commented: (DERBY-2902) AS IDENTITY (START WITH -9223372036854775808) fails
[ https://issues.apache.org/jira/browse/DERBY-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511379 ] Knut Anders Hatlen commented on DERBY-2902: --- Thanks Bryan, that makes sense. +1 to commit. AS IDENTITY (START WITH -9223372036854775808) fails --- Key: DERBY-2902 URL: https://issues.apache.org/jira/browse/DERBY-2902 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0 Environment: MacTel 10.4.10 JVM 1.6.0-dp Reporter: James Alan Shepherd Assignee: Bryan Pendleton Priority: Minor Attachments: parseLong.diff, parseLong_with_comment.diff When creating a table AS IDENTITY (START WITH -9223372036854775808) fails but AS IDENTITY (START WITH -9223372036854775807) succeeds. Guess this is a parsing SQL problem as the absolute value appears to be held in a long, which is not quite long enough at the positive end. -- 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-tabpanel#action_12511386 ] Jørgen Løland commented on DERBY-2872: -- I'm going to be giving a lightning talk at OSCON on the state of Derby and I want to know what if anything I can say about this feature. It sounds as though some increment of functionality will be delivered in the 10.4 timeframe. Will this functionality be complete enough that someone can use it? If so, can you characterize the kind of application that will benefit from the 10.4 increment? The intention is definitely to have working replication functionality in 10.4. Exactly what will be implemented and how depends heavily on what the community wants, so the guesses below may have to be changed. Also, if more people want to contribute to this task, more functionality will make it into 10.4 :-) I think it is very likely that in 10.4, replication will work. Some manual steps will probably be required, e.g. to start the fail-over logic. The replication functionality will be usable by all applications that want higher availability than a single (point of failure) server can provide. However, having to manually start fail-over may be unacceptable (take too much time) for applications with the highest availability requirements. Furthermore, the application should not contain super-secret data since security issues are likely to not make it into this release. But again, the priorities may change as community discussions progress. Add Replication functionality to Derby -- Key: DERBY-2872 URL: https://issues.apache.org/jira/browse/DERBY-2872 Project: Derby Issue Type: New Feature Components: Miscellaneous Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: 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_script.txt 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.
Re: 10.3 Release Notes
Myrna van Lunteren wrote: One of the hardest and most time-consuming things in preparing the release was creating the Release Notes. We have the release notes generator...But it presumes xml reports to have been magically created, and it does not have a mechanism to identify the new features. I acknowledge that making release notes are a time consuming task, and making release notes will always be a compromise between effort and quality. I guess the question we should ask is how can we get sufficient accuracy without making the work too time-consuming. In addition to the issues you raise, I feel that one major problem with generated release notes is that the summaries for JIRA issues often do say much about what have been fixed. I guess there are two alternatives we can try to improve that: 1. Urge the responsible developer to make sure the summary is descriptive. 2. Only include issues with specific release notes attached. This means that one will require such release notes all for issues that should be mentioned in the release note, not just for issues with application impact. Alternative 2 implies that the responsible developer for an issue will also be given the responsibility to decide whether an issue should be included in the release note or not. Maybe we should make the rule that only issues with the release note required field checked will be included in the release note. This would free the release manager from the burden of deciding what should be part of the release note, at the risk of reduced quality due to developers not marking their issues the way they are supposed to. In past releases, we had the 'CHANGES' file, but because it seemed to list the same bugs as the Release-Notes I removed it. This may have been the wrong thing to do...(every apache project needs to log the changes somehow). The advantage of a CHANGES file is that not everything needs to be included in the release note. It gives more freedom to create a release notes that is useful to Derby users. A big problem is also lack of standard usage in JIRA. Take sub-tasks - include them or not? What if the master task is still open because of 1 or 2 sub issues or tasks are still open? (e.g. 1478, although that's an improvement, not a bug). In other master issues, changes have gone in for both the master task and the subtask. What to do? Should issues get forced closed, with more work continuing in a subsequent bug while work is still going on when changes *have* gone in? How about issues where there are links, rather than subtasks, indicating one issue is 'part of' another; should the ones that are 'part of' not go in the release notes? Another concern is our practice for 'affects'. Because it is not required to annotate whether a bug is confirmed to exist or not in a previous release, or, for that matter, to even annotate the 'affects' at all, some bugs marked affects 10.3 might have been around before... So, creating a list of only bugs that existed before and have been fixed now, is particularly hard to compile in an automated way. I think if it was well defined how release notes were generated, one could give more responsibility to individual developers and make them do the necessary work to make an issue appear in the release note. (E.g., Developer: The bug I fixed is not listed in the release note! Release Manager: You need to mark it as affects 10.2 to make it show up). I think it would also help if the Release Manager, several times in the weeks prior to a release generated the release note and posted it on derby-dev and urged the developers to check that the issues they have been working on is properly listed. Note, by the way, that Dan brought up a similar concern re the release notes (DERBY-2840). Anyway, if we need another release round, I can modify the release notes. Otherwise, I'm inclined to leave them as is...Is that OK? I am not going to insist on anything, but I feel that a list of fixed bugs that are automatically generated based on what affects earlier releases would be much more useful (even if it may be less accurate) than the current list. If we do change them, what *should* be in them, then? I gather: - A section for 'new features' - without splitting into categories The ReleaseNotesGenerator needs to be adjusted for this new section Yes, definitely. For future releases, I suggest that we generate this based on issues that are marked as new features and that has an attached release note. This release note should then describe the implemented feature. For this release, it seems that some new features are marked improvement, instead. I feel that any changes in functionality or interfaces (small or large) should be marked as 'new features'. - A section for bug fixes - I assume only type bug and improvement? I am not sure about improvements. Many of them are code internal issues (e.g., renaming of class, restructuring of
Re: 10.3 - to release or not to release?
Kathey Marsden wrote: Myrna van Lunteren wrote: On 7/9/07, Stanley Bradbury [EMAIL PROTECTED] wrote: Hi Myrna - Thanks for the through release report. I took a look at the critical bug list and am concerned about the regression that causes locking problems: DERBY-2892 https://issues.apache.org/jira/browse/DERBY-2892 - this is a regression of the DERBY-255 fix and, though it was introduced in 10.2, should be addressed quickly. Has anyone look at the checkin that might have caused the regression? No one has signed up. Hi Myrna, I personally tend to think the release should be held up for this fix. If we take the philosophy that we don't have to fix a regression because it regressed a while ago we will constantly lose ground. It looks like the fix though will be different in 10.2 versus 10.3. I am looking at 10.2, but am not totally confident that I can get it fixed in short order. I would most appreciate if someone familiar with lob locators could take a look at the 10.3 fix. I will take a look at how this can be solved for 10.3. However, I do not think this issue is severe enough to stop the release. We are talking about a regression in 10.2 that was not discovered until over half a year after it was released. I am not saying that we do not need to fix this regression. I am saying that 10.3.1 can be released without a fix, but that it should be fixed by a subsequent 10.3 update release. In my opinion, we have gotten so far in the release process now that unless it is of significantly less quality than previous releases we should ship the release. -- Øystein
[jira] Commented: (DERBY-2475) invalid checksum
[ https://issues.apache.org/jira/browse/DERBY-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511417 ] James Calfee commented on DERBY-2475: - After the corruption, I restored the latest backup of the database which seemed to cure the problem. The select statement worked fine. However, soon after (new data was inserted) the corruption re-surface in the same way (not sure which row). I'm sorry that I do not have this copy; only the copy after the corruption. This happened on my development database so I probably had to Kill the Java VM. This computer has been very stable. The database files were stored on standard Inspiron E1505 hard drive from on a reiserfs partition (local, non-RAID, non-RAM). Output from the sysinfo program: -- Java Information -- Java Version:1.5.0_08 Java Vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-1.5.0-sun-1.5.0.08/jre Java classpath: /home/slim/java/db-derby-10.2.2.0-bin/lib/derby.jar:/home/slim/java/db-derby-10.2.2.0-bin/lib/derbynet.jar:/home/slim/java/db-derby-10.2.2.0-bin/lib/derbytools.jar:/home/slim/java/db-derby-10.2.2.0-bin/lib/derbyclient.jar OS name: Linux OS architecture: i386 OS version: 2.6.17-10-generic Java user name: slim Java user home: /home/slim Java user dir: /home/slim/java/db-derby-10.2.2.0-bin/bin java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [/home/slim/java/db-derby-10.2.2.0-bin/lib/derby.jar] 10.2.2.0 - (485682) [/home/slim/java/db-derby-10.2.2.0-bin/lib/derbytools.jar] 10.2.2.0 - (485682) [/home/slim/java/db-derby-10.2.2.0-bin/lib/derbynet.jar] 10.2.2.0 - (485682) [/home/slim/java/db-derby-10.2.2.0-bin/lib/derbyclient.jar] 10.2.2.0 - (485682) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.2.2.0 - (485682) Found support for locale: [de_DE] version: 10.2.2.0 - (485682) Found support for locale: [es] version: 10.2.2.0 - (485682) Found support for locale: [fr] version: 10.2.2.0 - (485682) Found support for locale: [hu] version: 10.2.2.0 - (485682) Found support for locale: [it] version: 10.2.2.0 - (485682) Found support for locale: [ja_JP] version: 10.2.2.0 - (485682) Found support for locale: [ko_KR] version: 10.2.2.0 - (485682) Found support for locale: [pl] version: 10.2.2.0 - (485682) Found support for locale: [pt_BR] version: 10.2.2.0 - (485682) Found support for locale: [ru] version: 10.2.2.0 - (485682) Found support for locale: [zh_CN] version: 10.2.2.0 - (485682) Found support for locale: [zh_TW] version: 10.2.2.0 - (485682) -- Ubuntu = Linux, kernel version 2.6.17-10-generic java version 1.6.0 Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) This is really 1 CPU with a dual core: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2050 @ 1.60GHz stepping: 8 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 1 core id : 255 cpu cores : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor est tm2 xtpr bogomips: 3195.79 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2050 @ 1.60GHz stepping: 8 cpu MHz : 1600.000 cache size : 2048 KB physical id : 1 siblings: 1 core id : 255 cpu cores : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor est tm2 xtpr bogomips: 3192.13 invalid checksum Key: DERBY-2475 URL: https://issues.apache.org/jira/browse/DERBY-2475 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.2.2.0 Environment: windows xp, notebook, possibly broken hard drive! Reporter: Fabian
JMX-management and monitoring
Hi, I am working on management and monitoring through JMX in Derby. Prior work on this includes a patch in Derby-1387 that has some working functionality, i.e. viewing properties and shutting down a single database. I think this patch shows great potential for management features in Derby. The code uses the Apache Commons Modeler framework for defining Model MBeans, because developing these Beans completely manually is rather cumbersome and error prone. Model MBeans are the most flexible MBeans through the use of several metadata classes, which enables the managed resource and management interface to be specified at runtime. Upon further development of this module, I have tried to analyze the choice of MBeans for Derby. The use of different types of MBeans can of course be combined, but if there is no real need for the generic nature of Model MBeans, it might be a better choice to go with Standard MBeans as the main choice and not depend on any framework like Commons. This framework implies two additional JARs for Derby and increasing code complexity through XML-metadata and API-dependencies. The advantage of using this configuration is that existing resources can easily be instrumented for management through an XML-metadata file. I am not sure if this is true for Derby, because the resources can not always be instrumented automatically. An example is the Derby properties. These do not have a coherent access interface (depends on how properties are set or if defaults are used), so making getter-methods for these in a management module is not trival and should be done by hand. The advantages of using Model MBeans and thus a framework like Commons seem unclear to me at this point. Coding Standard or Dynamic MBeans can be done efficiently without tools, and as far as I can see they are more than powerful enough for management of Derby. I would appreciate any input on this matter, especially from someone with experience using JMX. Ole Gunnar Borstad
[jira] Updated: (DERBY-2892) Closing a resultset after retrieving a large 32665 bytes value with Network Server does not release locks
[ https://issues.apache.org/jira/browse/DERBY-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Øystein Grøvlen updated DERBY-2892: --- Kathey Marsden (JIRA) wrote: Clob and Blob explicitly state that they are valid for the duration of the transaction in which they are created. While I have been aware of this, I have not interpreted this to mean that the value could not change, just that it should be possible to use it to access the underlying LOB column. However, I think you right that in the context of result sets one would expect the LOB object to represent a LOB value, not a LOB column. getBinaryStream says: Note: All the data in the returned stream must be read prior to getting the value of any other column. The next call to a getter method implicitly closes the stream, implying that the stream is much shorter lived. Thank you for making you aware of this. I guess I should have studied the API doc better. Is the implicitly closes part implemented by Derby? I can not remember to have seen any code for this. getCharacterStream does not say one way or another, but I assume it is parallel with getBinaryStream(). getAsciiStream says the same as getBinaryStream(). Network server does not know the difference between what was called in JDBC, getBlob() vs getBinaryStream() vs getBytes() for example. Prior to the fix for DERBY-326, Network Server would always call getBinaryStream() instead of getBlob and getCharacterStream() rather than getClob(). Since the lobs were materialized on the client we could still preserve the Blobs and Clobs until the end of the transaction. I am not sure how this might be different now with the locator work and how changing back to getBinaryStream() getCharacterStream() calls would impact that. With locators all operations in the network server are performed on Blob/Clob objects. For example, InputStream.read will map to Blob.getBytes on the server. Hence, I would assume that locks will be held. I have not checked, but this may now be true even for the embedded driver. I see two possible solutions to this problem: 1. Change how the locking is done. Maybe one could provide away to release locks when they are no longer needed. 2. Make a copy of the LOB value and allow concurrent updates. In 10.3 this is now possible since there is a mechanism for making temporary copies of LOBs. In order for this to be efficient, we should only make a copy when necessary. Hence, a copy-on-write mechanism would be useful. Another thing: I noticed that in Ole's LOB compatibility testing for 10.3 that the 10.3 version of the BlobClob4BlobTest, a locking test failed when running a 10.3 client with a 10.1 server (10.3 client with 10.2 server went OK). Does this mean that the test has been updated to accept this faulty behavior? 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.1 Environment: JDK: build 1.6.0_01-b06 (WinXP Gentoo/SuSE) Hardware: Intel x86 Client/Server environment Reporter: Thomas Niessen Priority: Critical 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)
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (10 issues) Subscriber: derby-dev Key Summary DERBY-2902 AS IDENTITY (START WITH -9223372036854775808) fails https://issues.apache.org/jira/browse/DERBY-2902 DERBY-2841 Convert jdbcapi/nullSQLText.java to JUnit https://issues.apache.org/jira/browse/DERBY-2841 DERBY-2854 Convert jdbc4/TestResultSetMethods.java to JUnit https://issues.apache.org/jira/browse/DERBY-2854 DERBY-2798 A new approach for main-memory database https://issues.apache.org/jira/browse/DERBY-2798 DERBY-2518 convert lang/releaseCompileLocks.sql to junit https://issues.apache.org/jira/browse/DERBY-2518 DERBY-2824 Improve error reporting, fix whitespace/formatting issues and replace tabs in UTF8Reader https://issues.apache.org/jira/browse/DERBY-2824 DERBY-223 Change programs under demo directory use consistent package names so IDEs do not report errors https://issues.apache.org/jira/browse/DERBY-223 DERBY-2815 ij doesn't start with J2ME / JSR169 / weme6.1 because attempting to find java.sql.Driver if ij.protocol property is specified https://issues.apache.org/jira/browse/DERBY-2815 DERBY-2807 Create a test for BlobClob compatibility on Derby server versions vs. Derby client versions. https://issues.apache.org/jira/browse/DERBY-2807 DERBY-2255 ij should indicate that it is waiting for more input in a multi-line interactive statement. https://issues.apache.org/jira/browse/DERBY-2255
Re: Optimization test result
Hi Julius, yes, the code is already in the derby codeline. It is under derbyTesting/system/optimizer. There is a reaadme file in that directory which will help you on how to run the test and details of the test. Please let me know if you have any questions Thanks Manjula On 7/10/07, Julius Stroffek [EMAIL PROTECTED] wrote: Hi Manjula, looks interesting. How have you produced those results? Is that optimizer test already part of derby or attached somewhere in JIRA? If not, can you share that code? I would like to do some experiments with optimizer and this might help me a lot. Thanks optimizer Julo Manjula Kutty wrote: Hi, I had run the optimization test and am attaching the report with 10.3beta. Looks like 10.3 performs better than 10.2 in query optimization. Please have a look -- Thanks, Manjula. -- Thanks, Manjula.
Re: what is the right way to fix the import/export security issues (DERBY-2436, DERBY-2437)?
I am not planning on working on this other than participating in the discussion. My take on this issue is that it is a serious issue that affects both 10.2 and 10.3. Personally I would not hold up 10.3 release waiting on the fix unless someone actively is working on it. Myrna van Lunteren wrote: To jump in...Mike, are you intending to fix this? In the foreseeable future? (If you are, then maybe it *is* worth holding the release waiting for it). Myrna
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511533 ] Rick Hillegas commented on DERBY-716: - Committed derby-716-01-basic-aa.diff at subversion revision 555032. I merged again today. All of the regression tests ran cleanly for me except for the wisconsin test. That test shows the following diff. It shows this diff even in a clean subversion client without my patch: 28712a28713 0 28715a28717 0 Test Failed. Re-enable VTIs -- Key: DERBY-716 URL: https://issues.apache.org/jira/browse/DERBY-716 Project: Derby Issue Type: New Feature Components: SQL Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-716-01-basic-aa.diff, functionTables.html, functionTables.html, functionTables.html Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages. This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2915) upgrade test fixture noConnnectionAfterHardUpgrade fails with 10.3.1.1
upgrade test fixture noConnnectionAfterHardUpgrade fails with 10.3.1.1 -- Key: DERBY-2915 URL: https://issues.apache.org/jira/browse/DERBY-2915 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.3.1.1 Reporter: Myrna van Lunteren The test fixture noConnectionAfterHardUpgrade in functionTests.tests.upgradeTests.BasicSetup fails with 10.3.1.1 with the following stack trace: 1) noConnectionAfterHardUpgrade(org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup)junit.framework.ComparisonFailure: Unexpected SQL state. expected:...P but was:...N at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:562) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:597) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:611) at org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.noConnectionAfterHardUpgrade(BasicSetup.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at 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 junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at 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 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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: java.sql.SQLException: Database at C:\derbyt\103\tst\upgr10311\system\singleUse\oneuse0 has an incompatible format with the current version of the software. The database was created by or upgraded by version 10.3. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Unknown Source) at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derbyTesting.junit.DataSourceConnector.openConnection(DataSourceConnector.java:54) at
[jira] Commented: (DERBY-2915) upgrade test fixture noConnnectionAfterHardUpgrade fails with 10.3.1.1
[ https://issues.apache.org/jira/browse/DERBY-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511548 ] Myrna van Lunteren commented on DERBY-2915: --- The test shows this: // Other SQL states might be valid, // once the beta flag is dropped. assertSQLState(XSLAP, e); Looks like XSLAN is also valid if beta=false. upgrade test fixture noConnnectionAfterHardUpgrade fails with 10.3.1.1 -- Key: DERBY-2915 URL: https://issues.apache.org/jira/browse/DERBY-2915 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.3.1.1 Reporter: Myrna van Lunteren The test fixture noConnectionAfterHardUpgrade in functionTests.tests.upgradeTests.BasicSetup fails with 10.3.1.1 with the following stack trace: 1) noConnectionAfterHardUpgrade(org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup)junit.framework.ComparisonFailure: Unexpected SQL state. expected:...P but was:...N at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:562) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:597) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:611) at org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.noConnectionAfterHardUpgrade(BasicSetup.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at 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 junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at 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 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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: java.sql.SQLException: Database at C:\derbyt\103\tst\upgr10311\system\singleUse\oneuse0 has an incompatible format with the current version of the software. The database was created by or upgraded by version 10.3. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection30.init(Unknown Source) at
[jira] Created: (DERBY-2916) Change/error? in 'Ordered null semantics' output from 'SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS()' in lang/wisconsin.java
Change/error? in 'Ordered null semantics' output from 'SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS()' in lang/wisconsin.java --- Key: DERBY-2916 URL: https://issues.apache.org/jira/browse/DERBY-2916 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: OS: All JVM: All Reporter: Ole Solberg Priority: Minor SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS() on 'Statement Text: select * from TENKTUP1 left outer join TENKTUP2 on ( TENKTUP1.unique1 = TENKTUP2.unique1 ) left outer join ONEKTUP on ( TENKTUP2.unique2 = ONEKTUP.unique2 ) left outer join BPRIME on ( ONEKTUP.onePercent = BPRIME.onePercent ) ' now returns extra 0 in ' Ordered null semantics on the following columns: 0 stop position: on first 1 column(s). Ordered null semantics on the following columns: 0 ' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511554 ] Daniel John Debrunner commented on DERBY-716: - Is there a need to add isRowMultiSet() to TypeDescriptor? It looks out of place in that interface. All the other isRowMultiSet() methods are on TypeId, and in fact the DataTypeDescriptor.isRowMultiSet() just calls the TypeId method. Also the TypeDescriptorImpl version just returns false which looks wrong, or an indication the method should not be on TypeDescriptor. Re-enable VTIs -- Key: DERBY-716 URL: https://issues.apache.org/jira/browse/DERBY-716 Project: Derby Issue Type: New Feature Components: SQL Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-716-01-basic-aa.diff, functionTables.html, functionTables.html, functionTables.html Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages. This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands. -- 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-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511554 ] Daniel John Debrunner edited comment on DERBY-716 at 7/10/07 1:09 PM: -- Is there a need to add isRowMultiSet() to TypeDescriptor? It looks out of place in that interface. All the other is() methods are on TypeId, and in fact the DataTypeDescriptor.isRowMultiSet() just calls the TypeId method. Also the TypeDescriptorImpl version just returns false which looks wrong, or an indication the method should not be on TypeDescriptor. was: Is there a need to add isRowMultiSet() to TypeDescriptor? It looks out of place in that interface. All the other isRowMultiSet() methods are on TypeId, and in fact the DataTypeDescriptor.isRowMultiSet() just calls the TypeId method. Also the TypeDescriptorImpl version just returns false which looks wrong, or an indication the method should not be on TypeDescriptor. Re-enable VTIs -- Key: DERBY-716 URL: https://issues.apache.org/jira/browse/DERBY-716 Project: Derby Issue Type: New Feature Components: SQL Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-716-01-basic-aa.diff, functionTables.html, functionTables.html, functionTables.html Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages. This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2893) INSERT and UPDATES succeed when permission has not been granted.
[
https://issues.apache.org/jira/browse/DERBY-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-2893:
--
Component/s: (was: Security)
(was: SQL)
Test
Priority: Major (was: Critical)
Downgrading this to a major test issue from critical bug.
INSERT and UPDATES succeed when permission has not been granted.
Key: DERBY-2893
URL: https://issues.apache.org/jira/browse/DERBY-2893
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0
Reporter: Daniel John Debrunner
Attachments: DERBY-2893_diff.txt
GrantRevokeTest had assert methods (assertInsertPrivilege etc.) of the form
try {
s.execute(command)
} catch (SQLException sqle)
{
if (!hasPrivilege)
assertSQLState(42502, e);
else
fail(...);
}
Note that no fail() assert was in the try portion after the SQL execution.
The statement should not work if hasPrivilege is false, but the test will
incorrectly pass if the statement succeeds. I added fail asserts with
revision 552922 like:
if (!hasPrivilege)
fail(expected no INSERT permission on table);
but these two for INSERT and UPDATE caused the test to fail (about 6 fixtures
fail) indicating that the statement succeeds even if the permission is not
granted.
It could be a test problem but needs some investigation.
The asserts for assertInsertPrivilege and asserUpdatePrivilege are commented
out to stop the test failing.
--
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-tabpanel#action_12511562 ] Kathey Marsden commented on DERBY-2892: --- rev 405037 updated the blobclob4BLOB test to accept the timeout. 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.1 Environment: JDK: build 1.6.0_01-b06 (WinXP Gentoo/SuSE) Hardware: Intel x86 Client/Server environment Reporter: Thomas Niessen Priority: Critical 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] Created: (DERBY-2917) Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code.
Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code. - Key: DERBY-2917 URL: https://issues.apache.org/jira/browse/DERBY-2917 Project: Derby Issue Type: Sub-task Components: Services, SQL Reporter: Daniel John Debrunner TypeDescriptor ideally represents a catalog type (column in a table, parameter in a procedure etc.) DataTypeDescriptor represents a runtime type Currently DataTypeDescriptor extends (implements) TypeDescriptor , but the relationship would be cleaner if DataTypeDescriptor had a TypeDescriptor (but was not a TypeDescriptor). One can at the moment obtain a TypeDescriptor from a DataTypeDescriptor using DataTypeDescriptor.getCatalogType() but most code just treats DataTypeDescriptor as a TypeDescriptor. This has lead to a couple of issues: 1) When a routine's parameter/return type is written out a DataTypeDescriptor is written to disk. This results in type information being repeated in the serialized form, thus increasing the on-disk size of a Derby database. 2) Collation derivation is runtime only (all persistent types by definition have implicit type) but the derivation is on the catalog Typedescriptor interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2917) Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code.
[ https://issues.apache.org/jira/browse/DERBY-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner reassigned DERBY-2917: Assignee: Daniel John Debrunner Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code. - Key: DERBY-2917 URL: https://issues.apache.org/jira/browse/DERBY-2917 Project: Derby Issue Type: Sub-task Components: Services, SQL Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner TypeDescriptor ideally represents a catalog type (column in a table, parameter in a procedure etc.) DataTypeDescriptor represents a runtime type Currently DataTypeDescriptor extends (implements) TypeDescriptor , but the relationship would be cleaner if DataTypeDescriptor had a TypeDescriptor (but was not a TypeDescriptor). One can at the moment obtain a TypeDescriptor from a DataTypeDescriptor using DataTypeDescriptor.getCatalogType() but most code just treats DataTypeDescriptor as a TypeDescriptor. This has lead to a couple of issues: 1) When a routine's parameter/return type is written out a DataTypeDescriptor is written to disk. This results in type information being repeated in the serialized form, thus increasing the on-disk size of a Derby database. 2) Collation derivation is runtime only (all persistent types by definition have implicit type) but the derivation is on the catalog Typedescriptor interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2917) Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code.
[ https://issues.apache.org/jira/browse/DERBY-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511565 ] Daniel John Debrunner commented on DERBY-2917: -- Changing this would lead to TypeId and DataTypeDescriptor not being formattable (I think). The serialized form of DataTypedescriptor writes out duplicate information TypeId BaseTypeIdImpl duplicate of information written out by TypeDescriptorImpl TypeDescriptorImpl BaseTypeIdImpl type attributes A DataTypedescriptor can be fully recreated from its TypeDescriptor(Impl), thus there is no need to write out anything else. Once DataTypedescriptor becomes only a runtime representation of the type, then all persistent types would be written out as a TypeDescriptor, using DataTypedescriptor.getCatalogType() as required. Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code. - Key: DERBY-2917 URL: https://issues.apache.org/jira/browse/DERBY-2917 Project: Derby Issue Type: Sub-task Components: Services, SQL Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner TypeDescriptor ideally represents a catalog type (column in a table, parameter in a procedure etc.) DataTypeDescriptor represents a runtime type Currently DataTypeDescriptor extends (implements) TypeDescriptor , but the relationship would be cleaner if DataTypeDescriptor had a TypeDescriptor (but was not a TypeDescriptor). One can at the moment obtain a TypeDescriptor from a DataTypeDescriptor using DataTypeDescriptor.getCatalogType() but most code just treats DataTypeDescriptor as a TypeDescriptor. This has lead to a couple of issues: 1) When a routine's parameter/return type is written out a DataTypeDescriptor is written to disk. This results in type information being repeated in the serialized form, thus increasing the on-disk size of a Derby database. 2) Collation derivation is runtime only (all persistent types by definition have implicit type) but the derivation is on the catalog Typedescriptor interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511566 ] Rick Hillegas commented on DERBY-716: - Thanks for taking a look at this patch, Dan. I think that isRowMultiSet() could be removed from TypeDescriptor. It's in there so that AliasDescriptor doesn't have to cast a TypeDescriptor to DataTypeDescriptor. I'm comfortable with that cast and agree that isRowMutliSet() looks awkward in TypeDescriptorImpl. Re-enable VTIs -- Key: DERBY-716 URL: https://issues.apache.org/jira/browse/DERBY-716 Project: Derby Issue Type: New Feature Components: SQL Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-716-01-basic-aa.diff, functionTables.html, functionTables.html, functionTables.html Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages. This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2916) Change/error? in 'Ordered null semantics' output from 'SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS()' in lang/wisconsin.java
[ https://issues.apache.org/jira/browse/DERBY-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511567 ] Daniel John Debrunner commented on DERBY-2916: -- It's probably one of my DERBY-2775 changes, but I don't know what that portion of the query plan really means. There was a chance before my changes that the nullability of a result column at runtime could be changed incorrectly by having multiple nodes referring to the same DataTypeDescriptor object and one node changing the nullability would change it for all other nodes that referenced the same object. That potential bug goes away with the changes, so that change in plan (but not results) may be a result of that. Change/error? in 'Ordered null semantics' output from 'SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS()' in lang/wisconsin.java --- Key: DERBY-2916 URL: https://issues.apache.org/jira/browse/DERBY-2916 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: OS: All JVM: All Reporter: Ole Solberg Priority: Minor SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS() on 'Statement Text: select * from TENKTUP1 left outer join TENKTUP2 on ( TENKTUP1.unique1 = TENKTUP2.unique1 ) left outer join ONEKTUP on ( TENKTUP2.unique2 = ONEKTUP.unique2 ) left outer join BPRIME on ( ONEKTUP.onePercent = BPRIME.onePercent ) ' now returns extra 0 in ' Ordered null semantics on the following columns: 0 stop position: on first 1 column(s). Ordered null semantics on the following columns: 0 ' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511568 ] Daniel John Debrunner commented on DERBY-716: - I see that isRowMultiSet is used to indicate the function is a table function. Would it not be clearer to have an explict state in RoutineAliasInfo that the function is a table function, rather than overloading the return type to indicate this? Also look at DERBY-2917, I'm trying to separate TypeDescriptor DataTypeDescriptor, thus the cast you didn't want to add won't be valid soon. Re-enable VTIs -- Key: DERBY-716 URL: https://issues.apache.org/jira/browse/DERBY-716 Project: Derby Issue Type: New Feature Components: SQL Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-716-01-basic-aa.diff, functionTables.html, functionTables.html, functionTables.html Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages. This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511570 ] Daniel John Debrunner commented on DERBY-716: - I see the type system details in the functional spec, but it's lacking some details. With a multiset type - What infomation will be stored in TypeDescriptorImpl, e.g. scale, precision, type name etc. - how does code access the types names in the multiset? Re-enable VTIs -- Key: DERBY-716 URL: https://issues.apache.org/jira/browse/DERBY-716 Project: Derby Issue Type: New Feature Components: SQL Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-716-01-basic-aa.diff, functionTables.html, functionTables.html, functionTables.html Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages. This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - tinderbox_trunk16 554996 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 554996/2007-07-10 18:42:15 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 3301298 089.63% derbyall 083758375 0 1882.60% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-554996.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/554996_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/554996.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-2917) Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code.
[ https://issues.apache.org/jira/browse/DERBY-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511573 ] Rick Hillegas commented on DERBY-2917: -- Thanks for tackling this, Dan. I find Derby's type system to be very puzzling. Cleaning up just this portion of it would be a great service. It is particularly odd that the types actually stored in the catalogs (for function return values at least) are not catalog types. There are a bewildering number of interfaces and classes which cooperate here: TypeIds, Formatable Ids, TypeDescriptors, DataTypeDescriptors. Then there are multiple type systems at work: the Java type system, the SQL type system, the Derby catalog type system, and the Derby runtime type system. It seems to me that one ought to be able to get by with just one type system that is rich enough to be usable all across Derby. It should be possible to collapse TypeIds, FormatableIds, TypeDescriptors, and DataTypeDescriptors into a single concept. I suspect that a lot of the confusion arose long ago because the division of labor between datatypes and datavalues was not very satisfactory. Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code. - Key: DERBY-2917 URL: https://issues.apache.org/jira/browse/DERBY-2917 Project: Derby Issue Type: Sub-task Components: Services, SQL Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner TypeDescriptor ideally represents a catalog type (column in a table, parameter in a procedure etc.) DataTypeDescriptor represents a runtime type Currently DataTypeDescriptor extends (implements) TypeDescriptor , but the relationship would be cleaner if DataTypeDescriptor had a TypeDescriptor (but was not a TypeDescriptor). One can at the moment obtain a TypeDescriptor from a DataTypeDescriptor using DataTypeDescriptor.getCatalogType() but most code just treats DataTypeDescriptor as a TypeDescriptor. This has lead to a couple of issues: 1) When a routine's parameter/return type is written out a DataTypeDescriptor is written to disk. This results in type information being repeated in the serialized form, thus increasing the on-disk size of a Derby database. 2) Collation derivation is runtime only (all persistent types by definition have implicit type) but the derivation is on the catalog Typedescriptor interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511576 ] Rick Hillegas commented on DERBY-716: - Hi Dan. I have added a comment to derby-2917. Thanks for tackling that project. I am very interested in this conversation. Unfortunately, tomorrow is my last day before I go on vacation (and then a conference) for two and a half weeks. So, please don't be put off by my impending radio-silence. I see that isRowMultiSet is used to indicate the function is a table function. Would it not be clearer to have an explict state in RoutineAliasInfo that the function is a table function, rather than overloading the return type to indicate this? It seemed to me that a Table Function was just a function which returned a Row Multi Set. I think it would certainly be reasonable to add an isTableFunction() method to RoutineAliasInfo. However, to avoid duplicating state, I think that that method would just turn around and inspect the return type to see if it were a Row Multi Set. - What infomation will be stored in TypeDescriptorImpl, e.g. scale, precision, type name etc. I'm not sure that a TypeDescriptorImpl would ever be built for a Row Multi Set as part of implementing Table Functions. The return type is never used at runtime and is only briefly inspected at compilation time in order to build the shape of the returned Table. I think you have created derby-2917 because it seems to you, too, that it's hard to understand how behavior is divided between the types in the catalog package and the types which actually are persisted to the catalogs. how does code access the types names in the multiset? This is done in FromVTI.createResultColumnsForTableFunction(). Re-enable VTIs -- Key: DERBY-716 URL: https://issues.apache.org/jira/browse/DERBY-716 Project: Derby Issue Type: New Feature Components: SQL Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-716-01-basic-aa.diff, functionTables.html, functionTables.html, functionTables.html Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages. This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result
[ https://issues.apache.org/jira/browse/DERBY-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511585 ] Bryan Pendleton commented on DERBY-2351: Committed derby_2351_v2.diff to the trunk as revision 555096. I'm leaving this issue open for a while, because I think this change is probably worth merging to the 10.3 branch. ORDER BY with expression with distinct in the select list returns incorrect result -- Key: DERBY-2351 URL: https://issues.apache.org/jira/browse/DERBY-2351 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0, 10.3.0.0 Environment: Any Reporter: Yip Ng Assignee: Bryan Pendleton Attachments: derby_2351.diff, derby_2351_v2.diff, reproTests.diff When distinct is in the select list and the query has order by with expression, the resultset produced contains an additional column. ij create table t1 (c1 int, c2 varchar(10)) 0 rows inserted/updated/deleted ij insert into t1 values (1,'a'),(2,'b'),(3,'c'); 3 rows inserted/updated/deleted select distinct c1, c2 from t1 order by c1; C1 |C2 -- 1 |a 2 |b 3 |c 3 rows selected ij select distinct c1, c2 from t1 order by c1+1; C1 |C2|3 =returns 3 columns, incorrect result returned -- 1 |a |2 2 |b |3 3 |c |4 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2902) AS IDENTITY (START WITH -9223372036854775808) fails
[ https://issues.apache.org/jira/browse/DERBY-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-2902: --- Derby Info: (was: [Patch Available]) AS IDENTITY (START WITH -9223372036854775808) fails --- Key: DERBY-2902 URL: https://issues.apache.org/jira/browse/DERBY-2902 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0 Environment: MacTel 10.4.10 JVM 1.6.0-dp Reporter: James Alan Shepherd Assignee: Bryan Pendleton Priority: Minor Attachments: parseLong.diff, parseLong_with_comment.diff When creating a table AS IDENTITY (START WITH -9223372036854775808) fails but AS IDENTITY (START WITH -9223372036854775807) succeeds. Guess this is a parsing SQL problem as the absolute value appears to be held in a long, which is not quite long enough at the positive end. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
10.3.1.1 release notes - build environment - not correct
To my shame I have to announce that I completely failed to update the release notes with my true build environment. I just copied the details from the 10.2.2.0 release... Instead, this was the true build environment: - Branch - Source code came from the 10.3 branch. - Machine - Microsoft Windows XP Professional Version 2002 Service Pack 2. - Ant - Apache Ant version 1.7 compiled on December 13, 2006 - JDK 1.4 - Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07_b05). - Java 6 - Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_01-b06). - OSGi - The osgi.jar was used to build org.apache.derby.osgi.EmbeddedActivator. Compiler - The 1.4.2_07-b05 javac was used to compile all classes except for the JDBC4 drivers. The JDBC4 driver classes were compiled using the 1.6.0_01-b06 javac. JSR 169 - J2ME support was built using IBM's weme6.1 j2me (jdbc.jar). Right now it looks as if we're not going to have another release candidate (holding out for more input on DERBY-2896); if true, I'll add a correction section to the web page. If we're having another release candidate I'll fix this. Myrna
Re: State of Derby at OSCON
Rick Hillegas [EMAIL PROTECTED] writes: I'm going to be giving a five minute lightning talk on the State of Derby at OSCON later this month (http://conferences.oreillynet.com/os2007/). I feel reasonably confident to say something about the 10.3 release but I'm not sure what to say about the community's 10.4 plans. The following look like plausible 10.4 improvements: VTIs (DERBY-716, I'm working on this) Some Replication (DERBY-2872, it looks like Jørgen and Narayanan are working on this) System Privileges (DERBY-2109, it looks like Martin is working on this) What else are people planning to do for the next feature release? This isn't a binding contract, just a guess if you've figured out what you I am planning have a look at SQL roles (DERBY-2207). Dag
10.3 branch backports...
Hi, I realize I haven't said what I wanted to go on the 10.3 branch at this point. I would like to minimize the changes to what has been identified as critical issues at this point; once we have a release, the 'normal' rules for backporting to a branch apply. So, Kathey, if you could backport your fix for the grantRevoke test fir DERBY-2893? *If* we need another candidate this fix should be in. Dan, if you could hold your backport plans for your intended changes? Same for Bryan and the fix for DERBY-2902; but you already said you'd wait, thx... Thx, Myrna
[jira] Created: (DERBY-2918) Errors in regression tests run against 10.3.1.1 release candidate
Errors in regression tests run against 10.3.1.1 release candidate - Key: DERBY-2918 URL: https://issues.apache.org/jira/browse/DERBY-2918 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.1 Reporter: Rick Hillegas I am seeing errors of the following sort in metadata, odbc_metadata, NSinSameJVM, and testProperties: *** Start: metadata jdk1.4.2_12 DerbyNetClient derbynetmats:derbynetmats 2007-07-10 12:55:29 *** 16 del JDBC Driver 'Apache Derby Network Client JDBC Driver', version 10.3 (10.3.1.1 -(EXPECTED SUBVERSION INFO)) 16a16 JDBC Driver 'Apache Derby Network Client JDBC Driver', version 10.3 (10.3.1.1 - (exported)) Test Failed. *** End: metadata jdk1.4.2_12 DerbyNetClient derbynetmats:derbynetmats 2007-07-10 12:55:41 *** I am also seeing errors like the following in the JUnit upgrade tests: 1) noConnectionAfterHardUpgrade(org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup)junit.framework.ComparisonFailure: Unexpected SQL state. expected:XSLA[P] but was:XSLA[N] at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:562) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:597) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:611) at org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.noConnectionAfterHardUpgrade(BasicSetup.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Caused by: SQL Exception: Database at /export/home/rh161140/derby/dummy/testRun/system/singleUse/oneuse27 has an incompatible format with the current version of the software. The database was created by or upgraded by version 10.3. at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Unknown Source) at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
[jira] Commented: (DERBY-2918) Errors in regression tests run against 10.3.1.1 release candidate
[ https://issues.apache.org/jira/browse/DERBY-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511604 ] Myrna van Lunteren commented on DERBY-2918: --- The upgrade test errors are logged as DERBY-2915. Errors in regression tests run against 10.3.1.1 release candidate - Key: DERBY-2918 URL: https://issues.apache.org/jira/browse/DERBY-2918 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.1 Reporter: Rick Hillegas I am seeing errors of the following sort in metadata, odbc_metadata, NSinSameJVM, and testProperties: *** Start: metadata jdk1.4.2_12 DerbyNetClient derbynetmats:derbynetmats 2007-07-10 12:55:29 *** 16 del JDBC Driver 'Apache Derby Network Client JDBC Driver', version 10.3 (10.3.1.1 -(EXPECTED SUBVERSION INFO)) 16a16 JDBC Driver 'Apache Derby Network Client JDBC Driver', version 10.3 (10.3.1.1 - (exported)) Test Failed. *** End: metadata jdk1.4.2_12 DerbyNetClient derbynetmats:derbynetmats 2007-07-10 12:55:41 *** I am also seeing errors like the following in the JUnit upgrade tests: 1) noConnectionAfterHardUpgrade(org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup)junit.framework.ComparisonFailure: Unexpected SQL state. expected:XSLA[P] but was:XSLA[N] at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:562) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:597) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:611) at org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.noConnectionAfterHardUpgrade(BasicSetup.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Caused by: SQL Exception: Database at /export/home/rh161140/derby/dummy/testRun/system/singleUse/oneuse27 has an incompatible format with the current version of the software. The database was created by or upgraded by version 10.3. at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at
[jira] Commented: (DERBY-2893) INSERT and UPDATES succeed when permission has not been granted.
[
https://issues.apache.org/jira/browse/DERBY-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511626
]
Kathey Marsden commented on DERBY-2893:
---
Looking at the test, we have:
public void testColumnPrivileges() throws Exception {
grant(select(c1),update(c3,c2),references(c3,c1,c2), s1,
t1, users[4]);
assertUpdatePrivilege(false, users[4], S1, T1, new String[]
{C2, C3});
}
But if I read the grant statement correctly, the first argument to
assertUpdatePrivilege should be true, because we granted update to c3,c2.
So, it makes sense why it was failing for Dan on trunk, for me on 10.3, but not
why I saw it pass on trunk with this set to false. Setting the first argument
to true passes the test on both trunk and 10.3, so I think still we are dealing
with a test issue, not a code issue if my logic that indeed user[4] was granted
update permission on C2, and C3.
INSERT and UPDATES succeed when permission has not been granted.
Key: DERBY-2893
URL: https://issues.apache.org/jira/browse/DERBY-2893
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0
Reporter: Daniel John Debrunner
Attachments: DERBY-2893_diff.txt
GrantRevokeTest had assert methods (assertInsertPrivilege etc.) of the form
try {
s.execute(command)
} catch (SQLException sqle)
{
if (!hasPrivilege)
assertSQLState(42502, e);
else
fail(...);
}
Note that no fail() assert was in the try portion after the SQL execution.
The statement should not work if hasPrivilege is false, but the test will
incorrectly pass if the statement succeeds. I added fail asserts with
revision 552922 like:
if (!hasPrivilege)
fail(expected no INSERT permission on table);
but these two for INSERT and UPDATE caused the test to fail (about 6 fixtures
fail) indicating that the statement succeeds even if the permission is not
granted.
It could be a test problem but needs some investigation.
The asserts for assertInsertPrivilege and asserUpdatePrivilege are commented
out to stop the test failing.
--
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-tabpanel#action_12511637 ] Kathey Marsden commented on DERBY-2892: --- I just thought I would give an update on my 10.2 work on this issue. I tried switching EXTDTAInputStream to use ResultSet.getCharacterStream() and ResultSet.getBinaryStream. Then instead of opening the stream again as was done with the Clob/Blob, I wrapped the binaryinputstream in a BufferedInputStream() so I could use mark() , read the first byte and then reset(). All of this worked for the repro for DERBY-255 but has caused protocol errors in the blobclob4BLOB test. Those I am still debugging. If anyone is interested in looking at the patch so far, I can attach it, otherwise I will just continue to work on it. 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.1 Environment: JDK: build 1.6.0_01-b06 (WinXP Gentoo/SuSE) Hardware: Intel x86 Client/Server environment Reporter: Thomas Niessen Priority: Critical 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] Commented: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511644 ] Stan Bradbury commented on DERBY-2896: -- Performed a basic test on a database (toursdb) created with territory=territory=es_MX - a simple progam that lists tables, exported keys and columns works fine (DbMD.getTables then getExportedKeys then getColumns). This could be a test issue or under a specific configuration. Since basic functionality is not impaired I think the priority of this issue can be lowered. Attached is a zipfile with the simple test program and toursDB created with es_MX territory for any one who might find this helpful. Db build: ij connect 'jdbc:derby:work\dbs\toursMx;create=true;territory=es_MX'; ij run 'ToursDB_schema.sql'; ij run 'loadCOUNTRIES.sql'; ij exit; %% java DBMetaData2 Loaded the derby JDBC driver. Get Tables Results Loop Got a TABLE named: AIRLINES . . Getting Exported Keys . . . Getting Columns . . . . Col: AIRLINE - Type: 1 Size: 2 . . . . Col: AIRLINE_FULL - Type: 12 Size: 24 . . . . Col: BASIC_RATE - Type: 8 Size: 52 . . . . Col: DISTANCE_DISCOUNT - Type: 8 Size: 52 . . . . Col: BUSINESS_LEVEL_FACTOR - Type: 8 Size: 52 . . . . Col: FIRSTCLASS_LEVEL_FACTOR - Type: 8 Size: 52 . . . . Col: ECONOMY_SEATS - Type: 4 Size: 10 . . . . Col: BUSINESS_SEATS - Type: 4 Size: 10 . . . . Col: FIRSTCLASS_SEATS - Type: 4 Size: 10 Got a TABLE named: CITIES . . Getting Exported Keys . . . Getting Columns . . . . Col: CITY_ID - Type: 4 Size: 10 . . . . Col: CITY_NAME - Type: 12 Size: 24 . . . . Col: COUNTRY - Type: 12 Size: 26 . . . . Col: AIRPORT - Type: 12 Size: 3 . . . . Col: LANGUAGE - Type: 12 Size: 16 . . . . Col: COUNTRY_ISO_CODE - Type: 1 Size: 2 Got a TABLE named: CIUDAD_DE_MEXICO . . Getting Exported Keys . . . Getting Columns . . . . Col: NOMBRE - Type: 12 Size: 24 . . . . Col: ESTADO - Type: 12 Size: 24 . . . . Col: EXCEPCI?N - Type: 4 Size: 10 Got a TABLE named: CIUDAD_DE_MEXICO2 . . Getting Exported Keys . . . Getting Columns . . . . Col: NOMBRE - Type: 12 Size: 24 . . . . Col: ESTADO - Type: 12 Size: 24 . . . . Col: EXCEPCI?N - Type: 4 Size: 10 == REST of OUTPUT not included DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed. --- Key: DERBY-2896 URL: https://issues.apache.org/jira/browse/DERBY-2896 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 Reporter: Daniel John Debrunner Priority: Critical I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so that it would test DatabaseMetaData within a collated database. I had to fix one item in JDBC.dropSchema() where a string constant was being compared to a system column while not in a system schema, but with that fixed the next error hit was executing DatabaseMetaData.getTables(). I will add the code to collation test with the use of DatabaseMetaDataTest commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stan Bradbury updated DERBY-2896: - Attachment: Test2896.zip Simplistic test case using DatabaseMetaData DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed. --- Key: DERBY-2896 URL: https://issues.apache.org/jira/browse/DERBY-2896 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 Reporter: Daniel John Debrunner Priority: Critical Attachments: Test2896.zip I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so that it would test DatabaseMetaData within a collated database. I had to fix one item in JDBC.dropSchema() where a string constant was being compared to a system column while not in a system schema, but with that fixed the next error hit was executing DatabaseMetaData.getTables(). I will add the code to collation test with the use of DatabaseMetaDataTest commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stan Bradbury updated DERBY-2896: - Attachment: (was: Test2896.zip) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed. --- Key: DERBY-2896 URL: https://issues.apache.org/jira/browse/DERBY-2896 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 Reporter: Daniel John Debrunner Priority: Critical Attachments: Test2896.zip I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so that it would test DatabaseMetaData within a collated database. I had to fix one item in JDBC.dropSchema() where a string constant was being compared to a system column while not in a system schema, but with that fixed the next error hit was executing DatabaseMetaData.getTables(). I will add the code to collation test with the use of DatabaseMetaDataTest commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stan Bradbury updated DERBY-2896: - Attachment: Test2896.zip Simplistic test case with proper license / rights assignment DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed. --- Key: DERBY-2896 URL: https://issues.apache.org/jira/browse/DERBY-2896 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 Reporter: Daniel John Debrunner Priority: Critical Attachments: Test2896.zip I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so that it would test DatabaseMetaData within a collated database. I had to fix one item in JDBC.dropSchema() where a string constant was being compared to a system column while not in a system schema, but with that fixed the next error hit was executing DatabaseMetaData.getTables(). I will add the code to collation test with the use of DatabaseMetaDataTest commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2919) Alter table .. Add .. Primary Key fails with Column not found when columnName contains localized characters - w/a available
Alter table .. Add .. Primary Key fails with Column not found when columnName contains localized characters - w/a available --- Key: DERBY-2919 URL: https://issues.apache.org/jira/browse/DERBY-2919 Project: Derby Issue Type: Bug Components: Localization Affects Versions: 10.3.1.1 Reporter: Stan Bradbury Priority: Minor Database created with territory=es_MX and table with colunName Excepci≤n (taken from exception text for ERROR XJ001: Excepci≤n de Java:...) trying to specify the column as the primary key using alter table fails: Db Creation URL: connect 'jdbc:derby:toursMx;create=true;territory=es_MX'; -- Create table Create table Ciudad_de_Mexico2 ( nombre varchar(24), estado varchar(24), Excepci≤n int ); -- Create PK ALTER TABLE Ciudad_de_Mexico2 ADD CONSTRAINT Mx_PK2 Primary Key ( Excepci≤n); -- ERROR 42831: 'EXCEPCI╙N' no puede ser una columna de clave primaria o clave - nica porque puede contener valores nulos. -- WORKAROUND: create the primary key when the table is created: Create table Ciudad_de_Mexico ( nombre varchar(24), estado varchar(24), Excepci≤n int constraint mx_pk Primary Key); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-2896: -- Summary: DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed. (was: DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with 42818 Comparisions between CHAR and CHAR not allowed.) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed. - Key: DERBY-2896 URL: https://issues.apache.org/jira/browse/DERBY-2896 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 Reporter: Daniel John Debrunner Priority: Critical Attachments: Test2896.zip I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so that it would test DatabaseMetaData within a collated database. I had to fix one item in JDBC.dropSchema() where a string constant was being compared to a system column while not in a system schema, but with that fixed the next error hit was executing DatabaseMetaData.getTables(). I will add the code to collation test with the use of DatabaseMetaDataTest commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - tinderbox_trunk16 555076 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 555076/2007-07-10 23:02:57 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 3301298 0 274.44% derbyall F:1,E:083768375 0 1863.84% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-555076.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/555076_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/555076.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-2915) upgrade test fixture noConnnectionAfterHardUpgrade fails with 10.3.1.1
[ https://issues.apache.org/jira/browse/DERBY-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511656 ] Myrna van Lunteren commented on DERBY-2915: --- Is it ok to just get the SQLState if it's either XSLAP or XSLAN, it's ok? Or do we need to get the version of the current jar and if it's a beta, check with XSLAP, if not, check with XSLAN? How would that best be achieved if we can't get a connection (so we can't use databasemetadata.getDatabaseProductVersion? upgrade test fixture noConnnectionAfterHardUpgrade fails with 10.3.1.1 -- Key: DERBY-2915 URL: https://issues.apache.org/jira/browse/DERBY-2915 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.3.1.1 Reporter: Myrna van Lunteren The test fixture noConnectionAfterHardUpgrade in functionTests.tests.upgradeTests.BasicSetup fails with 10.3.1.1 with the following stack trace: 1) noConnectionAfterHardUpgrade(org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup)junit.framework.ComparisonFailure: Unexpected SQL state. expected:...P but was:...N at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:562) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:597) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:611) at org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.noConnectionAfterHardUpgrade(BasicSetup.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at 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 junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at 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 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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: java.sql.SQLException: Database at C:\derbyt\103\tst\upgr10311\system\singleUse\oneuse0 has an incompatible format with the current version of the software. The database was created by or upgraded by version 10.3. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.init(Unknown Source) at
[jira] Commented: (DERBY-2919) Alter table .. Add .. Primary Key fails with Column not found when columnName contains localized characters - w/a available
[ https://issues.apache.org/jira/browse/DERBY-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511659 ] Mamta A. Satoor commented on DERBY-2919: Stan, if you have the stack trace, can you please post it in this jira entry? In the mean time, I will try to reproduce it myself. Alter table .. Add .. Primary Key fails with Column not found when columnName contains localized characters - w/a available --- Key: DERBY-2919 URL: https://issues.apache.org/jira/browse/DERBY-2919 Project: Derby Issue Type: Bug Components: Localization Affects Versions: 10.3.1.1 Reporter: Stan Bradbury Priority: Minor Database created with territory=es_MX and table with colunName Excepci≤n (taken from exception text for ERROR XJ001: Excepci≤n de Java:...) trying to specify the column as the primary key using alter table fails: Db Creation URL: connect 'jdbc:derby:toursMx;create=true;territory=es_MX'; -- Create table Create table Ciudad_de_Mexico2 ( nombre varchar(24), estado varchar(24), Excepci≤n int ); -- Create PK ALTER TABLE Ciudad_de_Mexico2 ADD CONSTRAINT Mx_PK2 Primary Key ( Excepci≤n); -- ERROR 42831: 'EXCEPCI╙N' no puede ser una columna de clave primaria o clave - nica porque puede contener valores nulos. -- WORKAROUND: create the primary key when the table is created: Create table Ciudad_de_Mexico ( nombre varchar(24), estado varchar(24), Excepci≤n int constraint mx_pk Primary Key); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2919) Alter table .. Add .. Primary Key fails with Column not found when columnName contains localized characters - w/a available
[ https://issues.apache.org/jira/browse/DERBY-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511660 ] Mamta A. Satoor commented on DERBY-2919: Actually, I just tried the test case in Norwegian territory since I understand it's error messages better than the Mexican error messages :) I think the problem has nothing to do with column name containing localized characters. It is throwing error because the column does not have not null defined on it and hence unique/primary key can't be defined on it using ALTER TABLE. Following is the ij session for Norwegian territory $ java org.apache.derby.tools.ij ij version 10.4 ij connect 'jdbc:derby:c:/dellater/db1Norway;create=true;territory=no;collation=TERRITORY_BASED'; WARNING 01J01: Database 'c:/dellater/db1Norway' not created, connection made to existing database instead. ij Create table Ciudad_de_Mexico2 ( nombre varchar(24), estado varchar(24), Excepci≤n int ); 0 rows inserted/updated/deleted ij ALTER TABLE Ciudad_de_Mexico2 ADD CONSTRAINT Mx_PK2 Primary Key (Excepci≤n); ERROR 42831: 'EXCEPCI╙N' cannot be a column of a primary key or unique key because it can contain null values. Alter table .. Add .. Primary Key fails with Column not found when columnName contains localized characters - w/a available --- Key: DERBY-2919 URL: https://issues.apache.org/jira/browse/DERBY-2919 Project: Derby Issue Type: Bug Components: Localization Affects Versions: 10.3.1.1 Reporter: Stan Bradbury Priority: Minor Database created with territory=es_MX and table with colunName Excepci≤n (taken from exception text for ERROR XJ001: Excepci≤n de Java:...) trying to specify the column as the primary key using alter table fails: Db Creation URL: connect 'jdbc:derby:toursMx;create=true;territory=es_MX'; -- Create table Create table Ciudad_de_Mexico2 ( nombre varchar(24), estado varchar(24), Excepci≤n int ); -- Create PK ALTER TABLE Ciudad_de_Mexico2 ADD CONSTRAINT Mx_PK2 Primary Key ( Excepci≤n); -- ERROR 42831: 'EXCEPCI╙N' no puede ser una columna de clave primaria o clave - nica porque puede contener valores nulos. -- WORKAROUND: create the primary key when the table is created: Create table Ciudad_de_Mexico ( nombre varchar(24), estado varchar(24), Excepci≤n int constraint mx_pk Primary Key); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
