http://permalink.gmane.org/gmane.comp.apache.db.derby.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64530 [ https://issues.apache.org/jira/browse/DERBY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653114#action_12653114 ] Rick Hillegas commented on DERBY-3969: -------------------------------------- Tests passed for me on derby-3969-01-aa-constraintsNoDatatype.diff except for diffs in stress multi tests. Committed at subversion revision 723184. Rick Hillegas (JIRA 2008-12-04T01:43:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64529 [ https://issues.apache.org/jira/browse/DERBY-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-2991: ---------------------------------- After reviewing the current patch, this does not look like a change appropriate for a backport. It is already 5000 lines of diffs and changes a basic concurrency building block of the btree code. Getting rid of the scan lock if it can be done with little or no performance penality does look like a good feature for a major release. It will simplify a lot of code, but would like to see a lot of testing before it gets into an official derby release. I do agree this is a good direction. Some of the code that originally depended on the scan protection lock no longer needs to as part of work that was later done to support the read uncommitted isolation level. Off the top of my head my areas of concern would be that the following operations work correctly in all combinations without the concurrency protection pro Mike Matrigali (JIRA 2008-12-03T23:13:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64528 [ https://issues.apache.org/jira/browse/DERBY-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas resolved DERBY-3964. ---------------------------------- Resolution: Fixed Rick Hillegas (JIRA 2008-12-03T22:53:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64527 Hi Knut, This topic came up when derby-dev discussed deprecating those releases. We seem to have deprecated the releases without posting their release notes somewhere convenient. As you note, this hinders users who want to understand the full implications of upgrading from a release prior to 10.3.1.4. You can get the missing release notes from the corresponding subversion tags: 10.3.2.1: https://svn.apache.org/repos/asf/db/derby/code/tags/10.3.2.1/RELEASE-NOTES.html 10.3.1.4: https://svn.apache.org/repos/asf/db/derby/code/tags/10.3.1.4/RELEASE-NOTES.html Regards, -Rick Knut Anders Hatlen wrote: Rick Hillegas 2008-12-03T22:48:31 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64526 [ https://issues.apache.org/jira/browse/DERBY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3969: --------------------------------- Derby Info: [Patch Available] Rick Hillegas (JIRA 2008-12-03T22:35:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64525 [ https://issues.apache.org/jira/browse/DERBY-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-2991: ---------------------------------- I am concerned about performance of always saving full key. This is going to cause both cpu and memory problems(garbage collection). As originally designed it was expected that this path would be rare so no optimization was ever done. The save by id path was the one optimized. Did you ever consider fixing by only changing the deadlock case, ie always giving up the scan position lock when one has to wait on a lock? This case should be rare, compared with the very normal case of group scan which happens by default for any scan of btree returning more than 16 rows for one query. sorry for late comment, was out on vacation when you started on this. Mike Matrigali (JIRA 2008-12-03T21:49:45 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64524 [ https://issues.apache.org/jira/browse/DERBY-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652969#action_12652969 ] Kathey Marsden commented on DERBY-2991: --------------------------------------- Thanks Knut for working on this issue. I know it is important to several users. For one of those users, Myrna backported the 1c patch along with the fix for DERBY-2878 to 10.3 to try out (Thanks Myrna). The user reported that it resolved all of their lock timeouts due to this issue and passed their regression tests. So great work Knut! We also have a request to backport this once done all the way to 10.1 for a user locked into that version. So my questions are: 1) Do you have any kind of general estimate when the final patch might be ready for trunk? 2) Do you have any reservations or concerns about my trying to backport the fix once complete to older codelines? Do you know if that is even feasible for 10.1? 3) Is there anything that I can do to Kathey Marsden (JIRA 2008-12-03T20:57:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64523 Hi, I am not able to find the release notes for 10.3.1.4 and 10.3.2.1 on the web pages any more. Where did they go? I know we removed the downloads for those releases because of DERBY-3347, but the release notes would still be useful for users moving from 10.2 to 10.4. Or if you want to check which new features we introduced in 10.3, as I wanted to do. The locations I checked were http://db.apache.org/derby/releases/release-10.3.1.4.cgi http://db.apache.org/derby/releases/release-10.3.2.1.cgi Is there some other place I should look for them? All the other releases have release notes at that location (just replace the version number in the URL with the release you're looking for). Knut Anders Hatlen 2008-12-03T20:41:57 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64522 [ https://issues.apache.org/jira/browse/DERBY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3969: --------------------------------- Attachment: derby-3969-01-aa-constraintsNoDatatype.diff Attaching derby-3969-01-aa-constraintsNoDatatype.diff. This fixes the known NPEs raised when declaring generated columns without datatypes but with constraints. Will run tests. 1) For FOREIGN and PRIMARY keys, the NPEs occurred because datatypes were being checked before the generation clauses were bound and the their datatypes determined. The solution was to move the datatype checks after the generation clauses are bound. 2) For CHECK constraints, the NPE occurred because the CHECK constraints were bound against a dummy table which was constructed before the generation clauses were bound. The solution was to update the datatypes in that table after binding the generation clauses. 3) For NOT NULL constraints, the NPE was occurring in the parser. I chose Rick Hillegas (JIRA 2008-12-03T20:17:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64521 [ https://issues.apache.org/jira/browse/DERBY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas reassigned DERBY-3969: ------------------------------------ Assignee: Rick Hillegas Rick Hillegas (JIRA 2008-12-03T20:15:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64520 [ https://issues.apache.org/jira/browse/DERBY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3969: --------------------------------- Description: The following script shows the problem for CHECK constraints. Other NPEs occur for PRIMARY, FOREIGN KEY, and NOT NULL constraints. drop table t_ccnd_1; Rick Hillegas (JIRA 2008-12-03T20:15:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64519 It is likely if such an approach were taken, that the builds used to produce the tests results published at the derby public site from ibm would continue to use a jdk14 jvm to do the build. So it would be good to make it easy to configure the build to continue to use 1.4 after whatever changes in this area is implemented. These are publicly available at: http://db.apache.org/derby/derby_tests.html under the IBM Regression Test Results link I also believe it useful to continue 1.4 support such that the small device jvm's can be supported. But agree that it would be useful going forward to allow new developers to work with jdk15, but provide as quick feedback as possible if they use 1.5 specific features that would break 1.4 derby support. If no implements the stub approach it may be useful to require patches to be tagged against which jvm they have been compiled against, to give a heads up to committers to check against 1.4 or not: http://people.apache.org/~myrnavl/derby_test_results/ Mike Matrigali 2008-12-03T19:53:27 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64518 [ https://issues.apache.org/jira/browse/DERBY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652913#action_12652913 ] Kathey Marsden commented on DERBY-728: -------------------------------------- The Properties javadoc says of load ... "the input/output stream is encoded in ISO 8859-1 character encoding. Characters that cannot be directly represented in this encoding can be written using Unicode escapes ; only a single 'u' character is allowed in an escape sequence." So users should be able to specify Chinese characters in the properties file with some effort. So, this might be an option if we can't find a DRDA solution. I would be interested to hear from users whether this a workable option. I can imagine the characters being in an install path and as part of the install the application would need to generate a derby.properties file with the aliases which might be a pain, but I am just speculating on usage. Kathey Marsden (JIRA 2008-12-03T19:27:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64517 [ https://issues.apache.org/jira/browse/DERBY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652641#action_12652641 ] stan edited comment on DERBY-728 at 12/3/08 9:33 AM: -------------------------------------------------------------- Here's a possible workaround for this problem that bypasses DRDA compliance issues. It's not elegant but makes it possible to address this issue without changing the DRDA protocol. The idea is supporting database path aliases as a property. This may have other benefits / uses as well. Your thoughts please. Idea: I know that some databases [maybe even DB2? DB2 uses DRDA and does not encounter this problem] store location (host / port / path / name [or alias]) information in a file. Could we implement something similar (database names/aliases) using derby properties that can be read by Network server from the derby.properties file to resolve database names on the connection URL? For the server-side you would only, I Stan Bradbury (JIRA 2008-12-03T17:33:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64516 [ https://issues.apache.org/jira/browse/DERBY-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3972: ---------------------------------- Description: IBM's Lotus Expeditor (http://www-01.ibm.com/software/lotus/products/expeditor/) includes the DesktopEE JRE which is described as: "The default Java™ Runtime Environment (JRE) of Lotus Expeditor is IBM's J9 VM with the DesktopEE class libraries, an IBM-optimized subset of Java 5 that offers a smaller footprint and faster class loading than standard Java Runtime Environments." My understanding is that it is a superset of JDK 1.4, so should run fine with Derby. The test harness needs to be updated to recognize this JVM so we can test with it. See http://publib.boulder.ibm.com/infocenter/ledoc/v6r2/topic/com.ibm.rcp.tools.doc.appdev/devapps_developingwiththejcldesktopjre.html for more information on DesktopEE. Environment: (was: IBM's Lotus Expeditor (http://www-01.ibm.com/software Kathey Marsden (JIRA 2008-12-03T17:23:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64515 Update test harness to run with DesktopEE JRE --------------------------------------------- Key: DERBY-3972 URL: https://issues.apache.org/jira/browse/DERBY-3972 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.4.1.3, 10.3.3.0, 10.5.0.0 Environment: IBM's Lotus Expeditor (http://www-01.ibm.com/software/lotus/products/expeditor/) includes the DesktopEE JRE which is described as: "The default Java™ Runtime Environment (JRE) of Lotus Expeditor is IBM's J9 VM with the DesktopEE class libraries, an IBM-optimized subset of Java 5 that offers a smaller footprint and faster class loading than standard Java Runtime Environments." My understanding is that it is a superset of JDK 1.4, so should run fine with Derby. The test harness needs to be updated to recognize this JVM so we can test with it. See http://publib.boulder.ibm.com/infocenter/ledoc/v6r2/topic/com.ibm.rcp.tools.doc.appdev/devapps_developi Kathey Marsden (JIRA 2008-12-03T17:21:44 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64514 I agree, thanks Ole this is very helpful! Is it possible to set things up so that the drill-down links on the web site are able to find the actual source code, so that the class-level coverage pages show the coverage of individual lines of code? When I clicked around, I eventually got to a place where it said "file not in source path". thanks, bryan Bryan Pendleton 2008-12-03T17:01:42 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64513 [Auto-generated mail] *Daily* 722524/2008-12-02 18:01:30 MET Failed Tests OK Skip Duration Suite ------------------------------------------------------- *Jvm: 1.6* lin 0 10858 10858 0 1649.66% suitesAll 0 13 13 0 .% jdbcapiAutoLoad 0 12 12 0 .% JDBCDriversAll 0 13 13 0 .% JDBCDriversClient 0 12 12 0 .% JDBCDriversEmbedded 0 235 235 0 82.47% derbyall 0 2 2 0 417.03% compatibility 0 2 2 0 .% demoSuite sles 0 10858 10858 0 1034.56% suitesAll 0 13 13 0 .% jdbcapiAutoLoad 0 12 12 0 .% JDBCDriversAll 0 13 13 0 .% JDBCDriversClient 0 12 12 0 .% JDBCDriversEmbedded 0 235 235 0 71.48% derbyall 0 2 2 0 230.64% compatibility 0 2 2 0 .% demoSuite sol F:1,E:0 10858 10857 0 Ole.Solberg-UdXhSnd/wVw< at >public.gmane.org 2008-12-03T16:55:40 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64512 Thanks Ole for doing this. It is important to keep our coverage numbers up and continue to improve them. This will hopefully provide the incentive we need. Kathey Kathey Marsden 2008-12-03T16:49:06 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64511 Issue Subscription Filter: Derby: JIRA issues with patch available (6 issues) Subscriber: derby-dev Key Summary DERBY-3964 NullPointerException when re-evaluating generated column during ON DELETE SET NULL referential action https://issues.apache.org/jira/browse/DERBY-3964 DERBY-481 implement SQL generated columns https://issues.apache.org/jira/browse/DERBY-481 DERBY-3788 Provide a zero-admin way of updating the statisitcs of an index https://issues.apache.org/jira/browse/DERBY-3788 DERBY-3270 Delayed (on-demand) creation of current user schema makes select from view belonging to other schema fail. https://issues.apache.org/jira/browse/DERBY-3270 DERBY-3193 SQL roles: Add documentation https://issues.apache.org/jira/browse/DERBY-3193 DERBY-2895 convert lang/declareGlobalTempTableJavaJDBC30.java to JUnit https://issues.apache.org/jira/browse/DERBY-2895 jira-1oDqGaOF3Lkdnm+yROfE0A< at >public.gmane.org 2008-12-03T16:35:45 http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/64510 For some time I have been running EMMA (http://emma.sourceforge.net/) on the 'suites.All' test and creating test coverage reports for Jvm 1.4, 1.5 and 1.6 as well as the accumulated report over these three runs. The results are now available at http://dbtg.thresher.com/derby/test/ / Weekly test coverage report: [http://dbtg.thresher.com/derby/test/coverage/] My intention is to update this page weekly. (There is currently a small manual step involved in that ;-) ) Ole Solberg 2008-12-03T15:55:07 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.apache.db.derby.devel