blobclob4BLOB failure (was Regression Test Failure! - Derby 431059 - Sun DBTG)
One of these is the strangest diff I have ever seen, that seems to have resulted from my checkin of Craig's patch. If anyone knows what is different with these please let me know, otherwise, I don't know how to fix it: 466a467,474 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 468,475d475 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 775a776,781 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 777,782d782 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 [EMAIL PROTECTED] wrote: [Auto-generated mail] *Derby* 431059/2006-08-12 19:46:02 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* NA NA NANA CYGWIN_NT-5.1_i686-unknown 6691685 2 120.67% CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 2691689 2 105.65% Linux-2.6.9-34.ELsmp_x86_64-x86_64 2691689 2 180.98% SunOS-5.10_i86pc-i386 2691689 2 138.55% SunOS-5.10_sun4u-sparc NA NA NANA SunOS-5.11_i86pc-i386 3691688 2 114.69% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-431059.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/431059.html *Jvm: 1.4* NA NA NANA CYGWIN_NT-5.1_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 2685683 4 105.38% Linux-2.6.9-34.ELsmp_x86_64-x86_64 2685683 4 213.03% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-431059.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/431059.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/431059.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Commented: (DERBY-1214) JDBC4 calls in the Brokered* classes need to be forwarded to more capable classes.
Did you try reverting your tree to the revision that the patch was made at (svn up -r revision), applying the patch, and then going back to the top of the trunk (svn up)? Often that solves the broken patch problem. David Rick Hillegas (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1214?page=comments#action_12412405 ] Rick Hillegas commented on DERBY-1214: -- I'm afraid I can't apply this patch. I get the following errors from the patch tool: patching file java/engine/org/apache/derby/iapi/jdbc/BrokeredPreparedStatement40.java patching file java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection40.java Hunk #1 FAILED at 41. Hunk #2 FAILED at 124. Hunk #3 succeeded at 298 (offset 116 lines). Hunk #5 succeeded at 339 (offset 116 lines). Hunk #7 succeeded at 365 (offset 116 lines). 2 out of 8 hunks FAILED -- saving rejects to file java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection40.java.rej patching file java/testing/org/apache/derbyTesting/functionTests/harness/RunList.java patching file java/testing/org/apache/derbyTesting/functionTests/harness/RunTest.java patching file java/testing/org/apache/derbyTesting/functionTests/util/TestConfiguration.java patching file java/testing/org/apache/derbyTesting/functionTests/util/BaseJDBCTestCase.java JDBC4 calls in the Brokered* classes need to be forwarded to more capable classes. -- Key: DERBY-1214 URL: http://issues.apache.org/jira/browse/DERBY-1214 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Assignee: Anurag Shekhar Attachments: derby-1214.diff Currently, the JDBC4 methods in the Brokered* classes raise SQLFeatureNotSupported. They should, where appropriate, forward their calls to more capable classes.
You are invited to a Derby get-together at JavaOne
To any and all of you who are in or around the Bay Area this week. JavaOne is happening and there are two things around Derby that I wanted to invite you to attend. The first is the Introduction to Apache Derby session that Dan and I are giving Tuesday at 5:45. Of course, most of you already know Derby, but it might be fun to lob nasty questions at Dan and I. Of course any you throw my way I'll just toss over to Dan :) Then at 7:30 at Jillian's in the Sony Metreon, just across from Moscone, there will be a big Derby get-together. There will be beer, wine, delicious snacks, and lots of great company. Many of the developers for Derby will be there, including a bunch of folks who have come over all the way from Norway. So, we'd love to see you there, it should be a good time. All the best, and happy Derbying! David
Re: What should I set JAVA_HOME to
Very helpful, thanks Rick. Rick Hillegas wrote: I'm not sure I followed this discussion. Forgive me if I'm talking at cross-purposes. I have just synced with the mainline and can verify the following: o You still need to set jdk16 in your ant.properties in order to build the JDBC4 support. This is the flag which the build uses to determine whether you want to compile JDBC4 support. This is true regardless of whether JAVA_HOME points at a 1.4, 1.5, or 1.6 installation. o The usage of this flag is still documented in BUILDING.txt. Search for jdk16. Hope I'm not muddling the discussion... -Rick David Van Couvering wrote: Well, something like If you are working with JDBC 4.0, you might want to set JAVA_HOME to the JDK 1.6 install location. This is not required but is the preferred way to do a build of Derby that includes classes that require the 1.6 compiler Also, when I went through BUILDING.txt, I didn't find the section saying how to set the jdk1.6 location in ant.properties (the old way of doing this) David Andrew McIntyre wrote: On 5/5/06, David Van Couvering [EMAIL PROTECTED] wrote: OK, thank.s But I am assuming the way moving forward is (once it becomes GA) to use JDK 1.6 as the JAVA_HOME, right? Anyway, I'll give that a shot. Yes, at some point we should probably document that as the preferred setup. But I also think we should continue to maintain the ability to build with previous JDKs until 1.6 is available on most of the platforms of interest outside of the Sun releases, like OS X, HP-UX, AIX, FreeBSD, zOS, etc. I also think that there needs to be some testing of an all-1.6 build. I haven't done any sort of comprehensive testing yet. I think BUILDING.txt needs to be updated to talk about this. Agreed. Any suggested wording? Otherwise I'll come up with something. andrew
Re: What should I set JAVA_HOME to
Hm, reading this patch, it seems a little convoluted. If you still have to set the jdk16 property, what's the value of setting JAVA_HOME to a 1.6 directory? What does it buy me? Perhaps we should explain, because reading it as it is, I tend to ask why would I want to do that? Thanks, David Andrew McIntyre wrote: On 5/5/06, David Van Couvering [EMAIL PROTECTED] wrote: Well, something like If you are working with JDBC 4.0, you might want to set JAVA_HOME to the JDK 1.6 install location. This is not required but is the preferred way to do a build of Derby that includes classes that require the 1.6 compiler So here's a patch with similar wording. Touched up a couple of other things I noticed while I was at it. Let me know what you think. andrew
Re: DRDA folks: Please review DERBY-846 patch
Hi, all. This patch is blocking further i18n work for me. I also don't want to have to do any merges and re-run derbyall. If you could get any comments in by noon, that would be appreciated, otherwise I will go ahead and check in and we can fix anything post-checkin. Thanks, David David W. Van Couvering wrote: This patch is the first patch internationalizing strings in the network part of the network client. I thought it would be good to get the eyes of some of the folks working in this area on this, to make sure it makes sense to you. http://issues.apache.org/jira/browse/DERBY-846?page=all Thanks, David
Re: DRDA folks: Please review DERBY-846 patch
Hi, Andreas. Thanks for reviewing this. I was trying to give the other-side-of-pond folks a day to review it by posting the patch and request for review last night. How much time do you need? Let me respond to your comments below. Andreas Korneliussen wrote: David W. Van Couvering wrote: Hi, all. This patch is blocking further i18n work for me. I also don't want to have to do any merges and re-run derbyall. If you could get any comments in by noon, that would be appreciated, otherwise I will go ahead and check in and we can fix anything post-checkin. This was quite a short deadline - if you want comments from the other side of the world, it would be wise to extend the deadline. I have only looked briefly at the diff file. I think that the changes in NetConnection40 and NetResultSet40 are not necessary (it appears the changes only fix code indentation), so to avoid getting other developers into merge conflicts, you could probably revert those changes. Another issue, is this error message: ERROR 08004: Connection authorization failure occurred. Reason: userid invalid. I think, for security policy reasons, the message should not reveal that userid is invalid. Hm, I agree. That said, invalid userid and invalid password are both standard DRDA values for the SECCHKCD parameter. I guess I can say invalid userid or password or invalid credentials for both of them, that's a pretty common approach. Also, shouldn't it read authentication failed, instead of authorization failure occured ? Yes, I agree, I can change that. (note: the patch did not really introduce this last issue, only fixed the message to have messageid as well) -- Andreas Thanks, David David W. Van Couvering wrote: This patch is the first patch internationalizing strings in the network part of the network client. I thought it would be good to get the eyes of some of the folks working in this area on this, to make sure it makes sense to you. http://issues.apache.org/jira/browse/DERBY-846?page=all Thanks, David
Re: DRDA folks: Please review DERBY-846 patch
I forgot to respond to one of your comments, see below... Andreas Korneliussen wrote: I have only looked briefly at the diff file. I think that the changes in NetConnection40 and NetResultSet40 are not necessary (it appears the changes only fix code indentation), so to avoid getting other developers into merge conflicts, you could probably revert those changes. The reason I did this was very selfish. I have a script that runs through all the code and tries to find as many places where a client-side SqlException is created. I then use this script to generate a test that makes sure that these exceptions are being created correctly: e.g. they use a message id that has a matching message, and that they pass the right number of arguments. This has turned out to be *very* valuable. The problem is, for reasons I won't get into, the changes I made to NetConnection40 and NetResultSet40 were to prevent the script from breaking. I could have modified the script, but it was a lot of work, and this was an easy change. I hope the merge impact isn't too heavy, this little change saved me a lot of time. If you think it's going to be a big issue, let me know. David
Re: Derbyall runtimes, 10.1, and Security Manager
Wouldn't it be reasonable for developers to run without security manager and for the regression tests to run with? We are not expecting regular breaks of security with our checkins, are we (although it can and does occur)? Thanks, David Rick Hillegas wrote: Hi Bryan, When playing around with individual tests--enabling and disabling the SecurityManager--I have noticed that our tests run considerably slower when launched under the SecurityManager. I don't have any sense of how much of the problem is just a tax we have to pay for security. Sounds like your experiments may have confirmed that the problem is not isolated to our test environment. It's definitely worth profiling this drag so that 1) we can factor security calls to the outer loop 2) we can appropriately set our customers' expectations Regards, -Rick Bryan Pendleton wrote: I had occasion recently to be porting a few bug fixes from the trunk to 10.1, and so I happened to be running derbyall on 10.1. I don't really want to re-ignite the debate over derbyall runtime, but the difference in duration between a derbyall run on the trunk, and a derbyall run on 10.1, was really remarkable. Then, as part of working on DERBY-1229, I happened to be running a lot of interactive experiments both with and without the security manager. And I noticed that when I ran Derby code with the security manager enabled, the runtime speed was noticeably slower. So I'm wondering, is it possible that a significant portion of the derbyall slowdown in the trunk is due to running with the security manager enabled, and, if so, is there anything we can do with that knowledge? thanks, bryan
Building with JDK 1.6 (was Re: Javadoc lies)
This is great news (for how we build with JDK 1.6, not the javadoc :( ), I didn't know if this was completed. Thanks, Andrew! Should those of working with JDK 1.6 start using the JAVA_HOME technique rather than the ant.properties technique? Has BUILDING.txt been changed? Thanks, David Rick Hillegas wrote: Hi Andrew, Thanks to your excellent work on derby-1078, it appears that we use the 1.6 javac when compiling in a shell window whose JAVA_HOME points at a 1.6 installation. Thanks to your changes, the build targets tell the 1.6 compiler to regard pre-JDBC4 source as down-rev and to generate byte code that will run on jdk1.3. I ran the experiment you recommended: I compiled and then generated javadoc all in a shell window whose JAVA_HOME pointed at jdk1.6. This did not change the javadoc result. E.g., the javadoc still falsely asserted that our JDBC3 DataSources implemented the JDBC4 Wrapper interface. The result was not affected when I generated javadoc with the following ant switch (also in a 1.6 shell window): source=1.4 Regards, -Rick Andrew McIntyre wrote: On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Well, I don't know that the Mac fans on this list would be very interested in having everything built with the 1.6 JDK. To clarify, the recent changes that went in with DERBY-1078 mean that you can build with 1.4, 1.5, or 1.6, and the resulting build will run on 1.3, 1.4, 1.5, and 1.6. Rick, I think David's suggestion #2 may be the answer. Now that DERBY-1078 is fixed, you can build everything with the 1.6 compiler. What does 1.6 javadoc say if you compiled everything with the 1.6 compiler? andrew
Re: [VOTE] Halley Pacheco de Oliveira as committer
[X] +1 Yes, Halley should become a committer Jean T. Anderson wrote: This vote is for establishing Halley Pacheco de Oliveira as a documentation committer for Derby. Halley has translated the Derby Getting Started Guide and the Derby Reference to Brazilian Portuguese (DERBY-780, DERBY-1138) and tells me the Derby Server and Administration Guide is being worked on. Halley has submitted numerous patches to correct the English documentation (DERBY-1123, DERBY-1175, DERBY-1194, DERBY-1195, DERBY-1200, DERBY-1203, DERBY-1207, DERBY-1263, DERBY-1270). Voting will close 5pm PST Monday, May 8. [ ] +1 Yes, Halley should become a committer [ ] 0 I don't care. [ ] -1 No (Please give a reason)
Apache Derby in the browser - on ZDNet
Great (if poorly spell-checked) article by David Berlind about the potential for Derby to enable offline web applications. See http://blogs.zdnet.com/BTL/?p=2298 If you think this is cool (and of course you do :)), you can help make it more visible by digging it at http://digg.com/programming/Offline_AJAX_Finally_a_Reality_
DRDA folks: Please review DERBY-846 patch
This patch is the first patch internationalizing strings in the network part of the network client. I thought it would be good to get the eyes of some of the folks working in this area on this, to make sure it makes sense to you. http://issues.apache.org/jira/browse/DERBY-846?page=all Thanks, David
Re: [Db-derby Wiki] Update of CodingProjects by KatheyMarsden
Thanks, Kathey. You may already know this, but note that putting it here does not make it publicly available for students, you have to put it on the main SummerOfCode wiki referenced on the CodingProjects page. David Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Db-derby Wiki for change notification. The following page has been changed by KatheyMarsden: http://wiki.apache.org/db-derby/CodingProjects -- ||Add incremental support for JMX||David Van Couvering||Start with something simple like is the server up or down and grow from there.|| || || ||Automatic copying of log from the log directory to an archive|| || || || ||Implement an LRU-based cache manager to replace the current clock algorithm||Øystein Grøvlen?|| Derby currently uses a clock algorithm to determine which pages to replace in its page cache. We have indications that this algorithm is far from optimal for some type of loads. Many other database systems use variants of an LRU-based algorithm, i.e. the pages that are least recently used will be candidates for replacement. || [LRUCache] || + ||Network client Quality Improvements|| Kathey Marsden|| Derby introduced the network client JDBC driver with its 10.1.1.0 release. There is still important quality work pending to match the robustness of our embedded Driver. This is a great opportunity to learn about JDBC, XA, and DRDA protocol and become active in the Apache Derby development community.||NetworkClientQualityImprovements||??||
Re: [jira] Reopened: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.
Nah, the bug just went away, that's all :) David Bryan Pendleton wrote: Bryan Pendleton (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton reopened DERBY-125: --- Reopened to merge this fix to the 10.1 branch. This one may take me a few days. The subversion merge is straightforward and clean, and all the tests pass. Unfortunately, the regression test now passes even *without* the fix. This was a *very* delicate regression test to write (Army and I co-wrote it over a period of several weeks), so I want to take a bit of time to study this, and see if there's something deeper going on here, or whether I just have to fiddle the regression test a bit. thanks, bryan
Revision 397980 changes MessageId to ClientMessageId
Hi, all. It turns out I needed iapi/reference/MessageId.java on the client side, so I moved it to shared/common/reference. Then, to avoid class name confusion, I renamed client/am/MessageId to client/am/ClientMessageId. I just checked this change in (passes derbynetclientmats cleanly). This may cause some conflicts in your sandbox. David
Re: Javadoc lies
It seems to me the real problem is that the way we compile source and the way we compile javadoc are inconsistent. With that in mind, I have two thoughts, with no backing in understanding how things really work... 1) Fix javadoc compilation to be in line with source compilation: build it with two different versions of javadoc depending upon the source being javadoc'd. 2) Fix our source compilation to be consistent with javadoc -- that is, build everything with jdk 1.6. I thought we had looked at doing this using the option that indicates that the target is 1.4. Again, I am woefully short of facts, but they were two ideas I thought I'd put out there to see if they might help. David Rick Hillegas wrote: Right now the javadoc generated for jdk1.6 is telling a shocking lie. I can fix this but only by inducing javadoc to tell a different lie. I would like advice on how to get javadoc to tell the truth, the whole truth, and nothing but the truth. If that's not possible, I'd like to know which lie the community prefers. 1) How it is today. Right now, if you point your ant.properties at a 1.6 installation, we build javadoc with the 1.6 javadoc tool. The tool assumes that you built your whole classtree against 1.6 and that the compiler therefore caught certain kinds of errors. In particular, if a class successfully compiles under jdk1.4 against the jdk1.4 version of an interface, then the 1.6 javadoc tool assumes that the class implements additional methods added to that interface in jdk1.6. Here's an example of the problems this causes: a) EmbeddedDataSource, compiled under jdk1.4, implements the 1.4 version of javax.sql.DataSource b) The 1.6 javadoc falsely says that EmbeddedDataSource implements the Wrapper methods added to javax.sql.DataSource by jdk1.6 2) A possible fix and its countervailing lie It would be possible to use the 1.4 javadoc tool to build javadoc for all the classes compiled under 1.4. Then we could use the 1.6 compiler to build the whole classtree again. With a little jiggery-pokery, we might be able to copy the additional javadoc html into the 1.4 javadoc tree and use the 1.6 index.html to zipper the two trees together. Mind you, I haven't built this yet, I'm just waving my hands. For the example case above, we would end up with something like the following: c) EmbeddedDataSource would NOT assert that it implements the jdk1.6 Wrapper methods d) However, now EmbeddedDataSource would fail to say that it has an important subclass, EmbeddedDataSource40 3) Other solutions? Does anyone have a better solution? Better means easier and/or more truthful. 4) Lies and the lying liars who like them If not, which lie do you prefer: (1b) or (2d). Thanks, -Rick
Re: Javadoc lies
In suggesting it being built with the 1.6 JDK, I should have been explicit in my assumption that this would only be done *if* the resulting bytecodes were compatible with a 1.4 VM (except of course for those classes that are 1.6-specific, but which you would not encounter running under a 1.4 VM). David [EMAIL PROTECTED] wrote: Well, I don't know that the Mac fans on this list would be very interested in having everything built with the 1.6 JDK. Many of us have had a hard time convincing our IT departments to upgrade to Tiger so that we can even use the 1.5 JDK. (May 4th - counting the days). -- Original message -- From: David W. Van Couvering [EMAIL PROTECTED] 2) Fix our source compilation to be consistent with javadoc -- that is, build everything with jdk 1.6. I thought we had looked at doing this using the option that indicates that the target is 1.4.
Re: Revision 397980 changes MessageId to ClientMessageId
Thanks, Andrew. Now tell me how I could possibly have gotten this to build and pass tests with this mistake. David Andrew McIntyre wrote: On 4/28/06, David W. Van Couvering [EMAIL PROTECTED] wrote: Hi, all. It turns out I needed iapi/reference/MessageId.java on the client side, so I moved it to shared/common/reference. Then, to avoid class name confusion, I renamed client/am/MessageId to client/am/ClientMessageId. I just checked this change in (passes derbynetclientmats cleanly). This may cause some conflicts in your sandbox. I think you forgot to update the package name in the MessageId in java/shared. Fixed with revision 398017. andrew
Summer of Code projects: deadline is approaching
Hi, all. May 1 approacheth, which is when students can start making proposals. Take a look at http://wiki.apache.org/db-derby/CodingProjects and see if there is one you would like to mentor. If you are inspired to mentor one or more of these, or if you have another project in mind, please put your project on the Apache Wiki page at http://wiki.apache.org/general/SummerOfCode2006 Thanks, David
Re: Summer of Code projects: deadline is approaching
By the way, right now we have *no* Derby projects up there. Perhaps you were all waiting for me to do it :( David David W. Van Couvering wrote: Hi, all. May 1 approacheth, which is when students can start making proposals. Take a look at http://wiki.apache.org/db-derby/CodingProjects and see if there is one you would like to mentor. If you are inspired to mentor one or more of these, or if you have another project in mind, please put your project on the Apache Wiki page at http://wiki.apache.org/general/SummerOfCode2006 Thanks, David
Re: Revision 397980 changes MessageId to ClientMessageId
Yes, that's right, this change was in preparation for my next i18n patch where the client will start referring to it. But engine/org/apache/derby/iapi/reference/MessageId was modified to be an empty class that extends shared/org/apache/derby/shared/common/reference/MessageId. How did *that* compile correctly? I just looked at it right now in the sandbox where I made this change, and I see the error in NetBeans: cannot access org.apache.derby.shared.common.reference.MessageId: bad class file. So, I'm a bit stumped - it shouldn't have compiled, right? I feel cursed - every time I try to run a smaller test suite something goes wrong. I feel like I should run derbyall even if I change BUILDING.txt. Anyway, thanks for fixing the bug. David Andrew McIntyre wrote: On 4/28/06, David W. Van Couvering [EMAIL PROTECTED] wrote: Thanks, Andrew. Now tell me how I could possibly have gotten this to build and pass tests with this mistake. Well, ClientMessageId doesn't import or extend MessageId. It's initialized with values that are all static final strings from SQLState. MessageId doesn't seem to be referenced anywhere in java/client? ~/derby andrewm$ grep --recursive 'MessageId\.[ACDIJLM]' java/client ~/derby andrewm$ andrew
Build warning
I keep seeing this warning when I build now:
C:\derby\i18n3\trunk\java\client\org\apache\derby\client\net\NetConnection40.java:41:
warning: getTypeMap() in org.apache.derby.client.am.Connection
implements getTypeMap() in java.sql.Connection; return type requires
unchecked conversion
found : java.util.Map
required: java.util.Mapjava.lang.String,java.lang.Class?
public class NetConnection40 extends
org.apache.derby.client.net.NetConnection {
1 warning
Can anyone explain this?
Thanks,
David
Re: Build warning
OK, thanks for your detective work. Next question: do we have to live with this warning until we no longer support JDK 1.4, or is there a way to resolve this? David P.S. I could look into this myself but I have enough on my plate right now. It's my itch to complain, but not to try and figure out what we can do to fix it :) Bryan Pendleton wrote: David W. Van Couvering wrote: I keep seeing this warning when I build now: C:\derby\i18n3\trunk\java\client\org\apache\derby\client\net\NetConnection40.java:41: warning: getTypeMap() in org.apache.derby.client.am.Connection implements getTypeMap() in java.sql.Connection; return type requires unchecked conversion I suspect this message may have the clue you need: http://www.nabble.com/-jira-Updated%3A-%28DERBY-1234%29-Verify-that-we-raise-SQLException-when-calling-methods-on-closed-java.sql-objects-p4089499.html thanks, bryan
Review of Derby's JDBC4 implementation
See http://binkley.blogspot.com/2006/04/nifty-jdbc-40.html What I liked: everything worked! David
Re: Summer of Code projects - deadline approacheth
Sorry, this was a cut-and-paste from someone else's suggestion, I don't even know what this is about :) David Knut Anders Hatlen wrote: Suresh Thalamati [EMAIL PROTECTED] writes: David W. Van Couvering wrote: Hi, all. Students can make proposals from May 1 to May 8. The ASF page http://wiki.apache.org/general/SummerOfCode2006 is the official ideas page for the ASF that students will be looking at, and probably already are. I just updated http://wiki.apache.org/db-derby/CodingProjects with some ideas that some of you may find interesting. If there's a project on this list, or a project that you have thought of not on the list, that you'd like to mentor, please feel free to update the following web site http://wiki.apache.org/general/SummerOfCode2006 with your project. Thanks, David Hi David, interesting projects, Is the following a typo ? or am I missing some thing ? Implement an LRU-based cache manager to replace the current lock algorithm did u mean : replace the current cache algorithm I guess he meant clock algorithm.
Re: serialization of Derby DataSources
I had to look into this when I was playing around with a classloader for code sharing. Basically, by setting the serialVersionUID, you are telling the VM that you guarantee that the newer version of the class is compatible with the old version (in terms of serialization). If you don't set this, then you will get an exception saying the class is not compatible if the VM determines that version UID (basically a hash) is different. There is documentation explaining how this UID is determined, and I struggled to get it right, but finally I had to set the serialVersionUID. Note that you have to set the serial version UID on the *second* and subsequent versions of the class, it's not required for the first version of the class. Basically, you run serialver on the first version of the class, and then use this to set serialVersionUID in the second version. I wrote some tests to verify serialization compatibility between versions of classes but never got to the point of checking them in. They may be valuable, and could be added to our compatibility tests, so if you'd like I can poke around and find them. One bug I uncovered in my tests was that for one of the data sources the serialversion UID was not public, so I was getting failures. Now I can't remember if I checked in that fix or not. David Rick Hillegas wrote: I'm confused about the presence of serialVersionUIDs in the DataSources exposed by our network client (e.g., ClientConnectionPoolDataSource). I think I understand why these classes are serializable (JNDI wants to serialize them). But I don't understand why we are forcibly setting the serialization id. I don't see any documentation explaining the serialization problem this addresses, stating the implications for engineers editting these classes, or describing our expectations at version upgrade. Can someone shed some light on this? Thanks, -Rick
Re: Help: NetAgent.java has placeholders in hardcoded messages
Thanks, Øystein, that was what I determined also. I fixed the placement
of arguments so they are correct. But I have to think about your point
of this information not being useful. I tend to agree, I think the
stack trace should be sufficient actually. There's not a lot of useful
information here.
So if nobody is of an opposite opinion, I can turn it into a simple message:
A communication error has been detected: {0} where {0} is the message
of the underlying exception. I can then chain the underlying exception
and I think that should be sufficient. It's not like we would ever use
anything *besides* TCP/IP and sockets...
David
Øystein Grøvlen wrote:
It seems to me that these messages can never ever been verified. Also
in the case where values are provided, it does not match the leading
text. (E.g., location is given as the first parameter, but should have
been the third.) See my comment in another thread
http://article.gmane.org/gmane.comp.apache.db.derby.devel/5822
In my opinion, such detailed debug information does not belong in
standard SQL exceptions.
--
Øystein
David W. Van Couvering wrote:
Hi. Can anyone explain to me how this works? In the close_ method of
client.net.NetAgent.java there is the following code:
accumulatedExceptions =
new SqlException(logWriter_, e, A
communication error has been detected. +
Communication protocol being used: {0}. +
Communication API being used: {1}. +
Location where the error was detected: {2}. +
Communication function detecting the error:
{3}. +
Protocol specific error codes(s) {4}, {5},
{6}. +
TCP/IP + SOCKETS + Agent.close() +
InputStream.close() + e.getMessage() +
+ * + 0);
Note the massive use of placeholders, and then none of the values for
the placeholders are provided.
This is repeated three times throughout the close() method as
exceptions are accumulated.
I track through to the SqlException code and the message appears to be
simply stored verbatim and ultimately a chain of SqlExceptions are
thrown to the user, with the placeholders not filled in.
I did a little test to throw this exception unconditionally and, which
is what I would have expected, I get the following text:
java.sql.SQLException: A communication error has been detected.
Communication
protocol being used: {0}. Communication API being used: {1}. Location
where the
error was detected: {2}. Communication function detecting the error:
{3}. Protoc
ol specific error codes(s) {4}, {5}, {6}. TCP/IP SOCKETS Agent.close()
InputStre
am.close() blahblah * 0
Am I missing some magic here? Or is this just a bug that was never
uncovered?
Thanks,
David
More on mentors for the Summer of Code
FYI, the attached emails provides some guidance on who an appropriate mentor is. David ---BeginMessage--- On 4/21/06, David W. Van Couvering [EMAIL PROTECTED] wrote: I just wanted to clarify: can anyone be a mentor, or does it have to be a committer? Our preference is for ASF members or long-time ASF committers/PMC members. Our goal, if you will, is to introduce the students to the ASF. So, it doesn't help if that person doesn't understand how the ASF works because they are new. The mentor should be a 'guide' to that student. They should be participating in the community at-large, but the mentor on our side should be a resource to help the students navigate our vast bureaucracy. ;-) Also, someone told me that a project can have only one person on it, you can't have two-or-more person projects. Is that correct? Yes. -- justin ---End Message--- ---BeginMessage--- On 4/21/06, Andrus Adamchik [EMAIL PROTECTED] wrote: I hope this won't disqualify Cayenne project - we are formally new to the ASF, but not to the meritocracy-based open source development process (that is IMO more important to the students to learn than this particular bureaucracy). Also finding answers to someone else's questions may be a good way for us to learn non-obvious things about the foundation :-) The Incubator already has built-in 'mentors' as part of the overall process for the podling. So, that should be fine for Cayenne as there is a structure in place already. The particular case I'd like to avoid is a brand-new ASF committer who isn't really sure about how things work and just ends up dropping the ball rather than resolving questions that the students may have. That hurts the ASF and the student if the mentor drops the ball. But, sounds like you guys should be fine... -- justin ---End Message---
Summer of Code projects - deadline approacheth
Hi, all. Students can make proposals from May 1 to May 8. The ASF page http://wiki.apache.org/general/SummerOfCode2006 is the official ideas page for the ASF that students will be looking at, and probably already are. I just updated http://wiki.apache.org/db-derby/CodingProjects with some ideas that some of you may find interesting. If there's a project on this list, or a project that you have thought of not on the list, that you'd like to mentor, please feel free to update the following web site http://wiki.apache.org/general/SummerOfCode2006 with your project. Thanks, David
Re: serialization of Derby DataSources
Right, can't you override the readObject method or whatever it's called? (Sorry, too lazy to look up the javadoc) I have some tests, Rick. If you'd like I can send them to you. Alternately log a JIRA and I can attach the source to the JIRA. Can't actually spend the time to fully implement and check in the tests right now, maybe later. David Lance J. Andersen wrote: Rick Hillegas wrote: David W. Van Couvering wrote: My understanding was that they may persist across upgrades because the data source objects are serialized into a JNDI store. In general we can *add* non-transient fields but we can't remove or change them. Thanks for that warning about the JNDI store. It would be better if we could flush the old object from the JNDI store. Sigh. According to an experiment I just ran, the de-serialization silently fails to populate the added field with a meaningful value, even if you specify a default in the field declaration or in a no-arg constructor. The added field is forced to the Java default for that type. I think this is tricky enough to warrant comments in these classes. if you add fields, you need to code it so that they get initialized to a reasonable value with when de-serialized using an older copy of the object. Thanks again, -Rick I think also since we support the Referenceable interface, the object is reconstructed in a compatible way using our own code, rather than depending upon serialization's default mechanism. But that's where I'm still a little muddled. By the way, using the *exact* same compiler, I tried to gently modify a DataSource following all the rules I could imagine, and because I didn't know the serialVersionUID was accidentally made private, I kept getting an incompatible class error or whatever it's called. I was doing everything perfectly, and it was still breaking. Once I set the serialVersionUID to be public, peace reigned. David Rick Hillegas wrote: Thanks, Lance. I agree. We seem to have a muddle if someone adds a new non-transient field to one of these classes: either a) the engineer changes the serialVersionUID, giving rise to the problem you mention or b) the serialVersionUID isn't changed and deserialization fails because the new field is missing from the persisted stream. Hopefully we don't mean for these objects to persist across Derby upgrades. Hard to tell from the code. Regards, -Rick Lance J. Andersen wrote: Hi Rick, once the serialVerisonUID is there, you should not remove it as chaos can break out if the IDs start to differ. IMHO would leave them alone. One example is you have say someone using say derby version x with a an ID of 1 and then persisted the object... now u remove the ID in derby y and the compiler generates say -2 for the ID , you will encounter problems when you try and grab the persisted version as the IDs no longer match. Rick Hillegas wrote: Thanks, David. I'm afraid I'm still muddled. I think I understand the basic purpose of serialVersionUID: It's a compiler-generated checksum of the source which serialization uses as a sanity check. By explicitly setting this field, the engineer promises to keep the following contract: Although the class behavior may change between versions, the non-transient fields won't. But I'm still not grasping the serialization issue we're addressing here. How do we get into a situation where there are two different versions of one of these classes? Is anyone persisting these classes across upgrades of the Derby code? Perhaps all that's being addressed here is the following recommendation from the javadoc of java.io.Serializable: However, it is /strongly recommended/ that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations... I don't think we have this problem, though: at release time we produce a standard, vetted version of Derby for which the compiler is constant. Thanks for helping me puzzle through this. Regards, -Rick David W. Van Couvering wrote: I had to look into this when I was playing around with a classloader for code sharing. Basically, by setting the serialVersionUID, you are telling the VM that you guarantee that the newer version of the class is compatible with the old version (in terms of serialization). If you don't set this, then you will get an exception saying the class is not compatible if the VM determines that version UID (basically a hash) is different. There is documentation explaining how this UID is determined, and I struggled to get it right, but finally I had to set the serialVersionUID. Note that you have to set the serial version UID on the *second* and subsequent versions of the class, it's not required for the first version of the class. Basically, you run serialver on the first version of the class, and then use
Re: [Fwd: Re: Invitation to Participate in Summer of Code 2006]
That's an Apache decision Oystein Grovlen - Sun Norway wrote: David W. Van Couvering wrote: What we actually submit to the ASF Summer of Code Wiki, however, needs to be a project that makes sense for Summer of Code and needs to have a committer who has volunteered to mentor. Why does mentors have to be committers? Is that a Google or Apache decision?
Re: Problem with new SQLException hierarchy in 1.6
Sorry, it's very hard to know which threads to pay attention to. Let me go look at the whole thread and I'll try to respond. David [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Bryan Pendleton [EMAIL PROTECTED] writes: Thank you for digging into this. I noticed this cruft (but didn't go hunting for the problem) while cleaning up some other diffs in the 1.6 derbyall. Yes, please log a JIRA on this and link it to DERBY-955, the master JIRA for 1.6 derbyall problems. Logged as DERBY-1178 It seemed like there was a second bug that you discovered here, too: you noticed that, due to poor input validation: it ends up trying to use the preformatted message as a real messageId and try to look up a localized version of the message. This obviously doesn't work Are we going to address *both* problems as part of 1178? Or do you think we need to have two different bug reports? Well, the way I see it, the first problem is definitely a bug, but the latter is more of a quality of implementation issue. That said, I think it should be fixed and I can create a JIRA for it. I just wanted to give David a chance to claim this, as part of his work on internationalization... I have not heard anything from David, so I have logged DERBY-1232 for this.
Help: NetAgent.java has placeholders in hardcoded messages
Hi. Can anyone explain to me how this works? In the close_ method of
client.net.NetAgent.java there is the following code:
accumulatedExceptions =
new SqlException(logWriter_, e, A
communication error has been detected. +
Communication protocol being used: {0}. +
Communication API being used: {1}. +
Location where the error was detected: {2}. +
Communication function detecting the error:
{3}. +
Protocol specific error codes(s) {4}, {5},
{6}. +
TCP/IP + SOCKETS + Agent.close() +
InputStream.close() + e.getMessage() + +
* + 0);
Note the massive use of placeholders, and then none of the values for
the placeholders are provided.
This is repeated three times throughout the close() method as exceptions
are accumulated.
I track through to the SqlException code and the message appears to be
simply stored verbatim and ultimately a chain of SqlExceptions are
thrown to the user, with the placeholders not filled in.
I did a little test to throw this exception unconditionally and, which
is what I would have expected, I get the following text:
java.sql.SQLException: A communication error has been detected.
Communication
protocol being used: {0}. Communication API being used: {1}. Location
where the
error was detected: {2}. Communication function detecting the error:
{3}. Protoc
ol specific error codes(s) {4}, {5}, {6}. TCP/IP SOCKETS Agent.close()
InputStre
am.close() blahblah * 0
Am I missing some magic here? Or is this just a bug that was never
uncovered?
Thanks,
David
Re: [Fwd: Re: Invitation to Participate in Summer of Code 2006]
Yes, absolutely, please list any ideas you think have value, even if there is no mentor. Perhaps a mentor will volunteer. Also, these ideas will have value beyond the Summer of Code and could be picked up by some other motivated student or newcomer. It could become an intern project or a university project. So please, go for it! What we actually submit to the ASF Summer of Code Wiki, however, needs to be a project that makes sense for Summer of Code and needs to have a committer who has volunteered to mentor. David Stanley Bradbury wrote: David W. Van Couvering wrote: Thanks, Jean. In the meantime, those of you with project ideas can post them to the wiki site at http://wiki.apache.org/db-derby/CodingProjects David -- SNIP -- I have an idea but am not qualified to mentor the project other than providing input on the design. Should I list the idea anyway without a mentor? The idea (no surprise to anyone who knows me) is to create a light-weight GUI tool along the lines of the old Cloudview tool. Any code mentors / UI developers want to sign-up for that?
ASF Summer of Code effort officially on
Hi, all. The Google Summmer Of Code activity for Apache Software Foundation has been officially announced (see the attached email to the DB PMC). It appears that a mentor must be a committer. However, anyone can submit ideas, and they are most welcome. We have two weeks to get our proposals up on the main Apache Wiki for the Summer of Code. If you can get your project ideas up in the next week, that would be great. You can add them here: http://wiki.apache.org/db-derby/CodingProjects Thanks! David
Re: [Fwd: Re: Invitation to Participate in Summer of Code 2006]
Thanks, Jean. In the meantime, those of you with project ideas can post them to the wiki site at http://wiki.apache.org/db-derby/CodingProjects David Jean T. Anderson wrote: David W. Van Couvering wrote: FYI... I'll work on participating with the larger Apache community I asked on community@ [1] . To get involved, join [EMAIL PROTECTED] -jean [1] http://mail-archives.apache.org/mod_mbox/www-community/200604.mbox/[EMAIL PROTECTED] snip
Re: diff in TestResultSetMethods
Hi, Rick. I suspect this is caused by my recent i18n checkin, which I did not run against jdbc40 test suite. I'm looking into this now. David Rick Hillegas wrote: I'm seeing the following failure in a clean client torn off the mainline. This is a diff in the DerbyNetClient run of the jdbc4 test TestResultSetMethods. I'm running under mustang build 78. MasterFileName = master/TestResultSetMethods.out 0 add Unexpected exception caught SQL Exception: 'ResultSet' already closed. SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 4 more Unexpected exception when invoking rowInserted(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getType(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getWarnings(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getMetaData(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getConcurrency(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getRow(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking rowUpdated(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getHoldability(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getFetchSize(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking setFetchSize(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getStatement(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking getFetchDirection(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking setFetchDirection(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking rowDeleted(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Unexpected exception when invoking clearWarnings(): SQL Exception: 'ResultSet' already closed. Caused by: org.apache.derby.client.am.SqlException: 'ResultSet' already closed. ... 8 more Test Failed. *** End: TestResultSetMethods jdk1.6.0-beta2 DerbyNetClient 2006-04-17 09:29:58 ***
Re: [jira] Commented: (DERBY-842) Internationalize messages in PreparedStatement to Section in org.apache.derby.client.am
Good idea, Knut, thanks for the tip.
David
Knut Anders Hatlen wrote:
David Van Couvering (JIRA) derby-dev@db.apache.org writes:
[ http://issues.apache.org/jira/browse/DERBY-842?page=comments#action_12374799 ]
David Van Couvering commented on DERBY-842:
---
Knut comments:
quote
jdbc4/TestResultSetMethods.java fails too since on the client
ResultSet.checkForClosedResultSet() uses SQL state XJ012
(ALREADY_CLOSED) whereas EmbedResultSet.checkIfClosed() uses XCL16
(LANG_RESULT_SET_NOT_OPEN).
/quote
and Kathey mentions on email that we should strive for the SQL States to be the
same on embedded and network client drivers, to which I wholeheartedly agree.
The problem is, fixing this is turning out to be a bit tricky, because the
message for XCL16 is
XCL16.S=ResultSet not open. Operation ''{0}'' not permitted. Verify that
autocommit is OFF.
The reason this is a problem is becuase ResultSet.checkForClosedResultSet() is
a generic method called by many (about 30) methods of ResultSet, and the
particular operation being attempted is not specified.
So, I could fix this by
(a) changing the message for XCL16 to not specify the operation
(b) use the string unspecified in the client code (I'd internationalize the
string so it can be translated)
Any opinions? Otherwise I'll go with option (b)
Isn't this case similar to those where you have added .0 and .1 as a
suffix? For instance,
XCL16.S.0=ResultSet not open.
XCL16.S.1=ResultSet not open. Operation {0} not permitted.
On the other hand, Rick's suggestion (Throwable.getStackTrace) sounded
very fancy! :)
client/am/Versionj.ava
This class prints out a bunch of trace information about the client version. This is currently all hardcoded in English into the class. Should these strings be internationalized? I am thinking not since it's debug information. Any views on this? Thanks, David P.S. I tried to trace how the logwriter gets set, but wound up in a dead end with a constructor for NetConnection that appears to never get called in our source... How *does* the logwriter get set on a connection?
Apache Derby invited to participate in Google Summer of Code
Great news! We have been invited to participate in the Google Summer of Code. I am signing up as the overall community representative and will work to get this set up with Google. Barring any unforeseen glitches in this process, I think we should be good to go. In the meantime, we should get prepared by setting up as many interesting projects we can think of that a team of one or more top-notch student coders can do over a summer. This is an opportunity to get some visibility, get some great improvements to Derby, and potentially recruit some great new community members. I have set up a Wiki page for coding projects. I tried to make it generic in case anyone wants to sign up, but it is geared towards the requirements of the Summer of Code (a three month project for one or more newcomers). If there is a project you think would be great to get done, please add it to the site. NOTE that each project requires one or more mentors who can help guide the team through their design and implementation and answer any questions or concerns they may have. See http://wiki.apache.org/db-derby/CodingProjects Thanks, and let me know if you have any questions. David
[Fwd: Re: Invitation to Participate in Summer of Code 2006]
FYI, we're officially in! See http://www.google.com/soc I'll work on filling out the information for Apache Derby. Those of you who would like to be mentors (and the more the better), please follow the instructions in the attached email. All the best, David ---BeginMessage--- Hi David, That's exactly what I need - thank you! We've enabled your access for the SoC site. Please take a moment to update your personal information and your organization's information . If you already have project ideas available to publish, that's great; if not, you can update them later. We've left the mentor sign up URL off the main SoC page to discourage spam mentor applications, so please let your fellow mentors know that they can sign up at at http://code.google.com/soc/mentor_step1.html. As the organization's administrator, you will need to accept each mentor application and decide which mentors to grant administrator status to. Once your mentors are signed up they can use http://code.google.com/soc/mentor_home.html to interact with student applications once they start to arrive. You'll also be invited to join the Summer Administrators 2006 Google Group; we'll invite your fellow mentors to the group periodically once they sign up with your organization. Cheers, LH David W. Van Couvering wrote: Hi, Leslie. Thank you very much for your invitation, and Apache Derby would like to participate. I am not sure what you need for Google account information, but I created an account with my personal email address [EMAIL PROTECTED]. Is that what you need? Many thanks, David Leslie Hawthorn wrote: Hello David, Google is launching the Summer of Code program again this year and we would like to invite ApacheDerby to sign up to participate. You can peruse our Mentor FAQ http://code.google.com/soc/mentorfaq.html and Terms of Service http://code.google.com/soc/tos.html on the Summer of Code site http://code.google.com/soc/ for more information on this year's instance of the program. If you would like to participate in Summer of Code 2006, please email back with your Google Account https://www.google.com/accounts/ManageAccount information and we will use this information to create the first administrator account on the SoC site for ApacheDerby and send you instructions for accessing and updating the site. We look forward to working with you during this year's Summer of Code! Cheers, LH -- Leslie Hawthorn Open Source Program Coordinator Google Inc. -- Leslie Hawthorn Open Source Program Coordinator Google Inc. ---End Message---
[Fwd: Re: [Fwd: Re: Invitation to Participate in Summer of Code 2006]]
Sorry, didn't notice this was only to derby-user... ---BeginMessage--- So, we had a chat about this on IRC, and the general feeling with Andrew and Jean is that we should be under the umbrella of ASF an not our own separate project. It sounds like last year ASF arranged it with all the projects within ASF and there was a collaborative set of projects. I understand this makes sense, but I feel kind of bummed, now we have to compete for attention from all the other ASF projects, it was kind of nice being top level. But I totally it would look bad and unfair for us to be at the top and nobody else from ASF. So I'll work on this. Jean, Andrew, anything else you want to add? David Jean T. Anderson wrote: David W. Van Couvering wrote: FYI, we're officially in! See http://www.google.com/soc I think that url is supposed to be ... http://code.google.com/soc/ Apache Derby isn't showing up under the ASF -- was that intentional? -jean snip ---End Message---
Re: [Fwd: Re: [Fwd: Re: Invitation to Participate in Summer of Code 2006]]
Dan, you make excellent points. Andrew and Jean also give excellent points, but for some reason I am excited by your points, while Andrew and Jean's points make me feel somewhat sad and dutiful :) I will hold off doing anything until we get this resolved. I personally agree that this is Google's decision. David Daniel John Debrunner wrote: David W. Van Couvering wrote: So, we had a chat about this on IRC, and the general feeling with Andrew and Jean is that we should be under the umbrella of ASF an not our own separate project. Isn't that Google's decision? It sounds like last year ASF arranged it with all the projects within ASF and there was a collaborative set of projects. I understand this makes sense, but I feel kind of bummed, now we have to compete for attention from all the other ASF projects, it was kind of nice being top level. But I totally it would look bad and unfair for us to be at the top and nobody else from ASF. So I'll work on this. Not sure what's bad or unfair about it, the Derby project was just more pro-active (through David VC) in dealing with Google. Dan.
[Fwd: Re: Invitation to Participate in Summer of Code 2006]
FYI... I'll work on participating with the larger Apache community David ---BeginMessage--- Hi David, I just wanted to let you know that I've heard back and we will need Apache Derby to sign up to mentor under the Apache Software Foundation umbrella organization. Best, LH David W. Van Couvering wrote: Hi, Leslie. I have received feedback from others in our community that we really belong under the umbrella of Apache Software Foundation and should coordinate/integrate with them. Kind of too bad, I liked being top level, but at the same time I understand why our project shouldn't get special treatment. I am going to work with the ASF to see what we should do, but it is possible (likely) that I will have to ask you to remove our project from the top level. Many thanks, David Leslie Hawthorn wrote: Hi David, That's exactly what I need - thank you! We've enabled your access for the SoC site. Please take a moment to update http://code.google.com/soc/mentor_step1.html your personal information and your organization's information . If you already have project ideas available to publish, that's great; if not, you can update them later. We've left the mentor sign up URL off the main SoC page to discourage spam mentor applications, so please let your fellow mentors know that they can sign up at at http://code.google.com/soc/mentor_step1.html. As the organization's administrator, you will need to accept each mentor application and decide which mentors to grant administrator status to. Once your mentors are signed up they can use http://code.google.com/soc/mentor_home.html to interact with student applications once they start to arrive. You'll also be invited to join the Summer Administrators 2006 Google Group http://groups.google.com/group/Summer-Administrators-2006; we'll invite your fellow mentors to the group periodically once they sign up with your organization. Cheers, LH David W. Van Couvering wrote: Hi, Leslie. Thank you very much for your invitation, and Apache Derby would like to participate. I am not sure what you need for Google account information, but I created an account with my personal email address [EMAIL PROTECTED] Is that what you need? Many thanks, David Leslie Hawthorn wrote: Hello David, Google is launching the Summer of Code program again this year and we would like to invite ApacheDerby to sign up to participate. You can peruse our Mentor FAQ http://code.google.com/soc/mentorfaq.html and Terms of Service http://code.google.com/soc/tos.html on the Summer of Code site http://code.google.com/soc/ for more information on this year's instance of the program. If you would like to participate in Summer of Code 2006, please email back with your Google Account https://www.google.com/accounts/ManageAccount information and we will use this information to create the first administrator account on the SoC site for ApacheDerby and send you instructions for accessing and updating the site. We look forward to working with you during this year's Summer of Code! Cheers, LH -- Leslie Hawthorn Open Source Program Coordinator Google Inc. -- Leslie Hawthorn Open Source Program Coordinator Google Inc. -- Leslie Hawthorn Open Source Program Coordinator Google Inc. ---End Message---
Re: !$!% derbyall
I usually do run derbynetclientmats. But sometimes I adjust message text to make it more generic/have it make more sense for both client and engine. And sometimes the message text is just plain wrong or confusing. So this affects the embedded tests. David Daniel John Debrunner wrote: David W. Van Couvering wrote: rant on Sorry, but it is so frustrating. I started a derbyall run at 9 this morning, and it was still running this evening. My CPU was at 100%, I could get barely any work done, and then my machine hung up, I had to reboot, and the way our harness works you have to start *completely from scratch* -- there is no way to start from the beginning. /rant off If I weren't so busy trying to get some this i18n work completed I would do the work of defining a smaller MATS. If you are doing client i18n work then why are you running derbyall? Why not just run derbynetclientmats? Dan.
Patch for running RunSuite with a list of suites (was Re: !$!% derbyall)
This is great, Andrew, thanks! Can anyone tell me how I find out, if derbyall or any suite goes down half-way through, what suites have run so far, and which ones have passed and which ones have failed? Thanks, David Andrew McIntyre wrote: On 4/12/06, Andrew McIntyre [EMAIL PROTECTED] wrote: On 4/12/06, David W. Van Couvering [EMAIL PROTECTED] wrote: rant on Sorry, but it is so frustrating. I started a derbyall run at 9 this morning, and it was still running this evening. My CPU was at 100%, I could get barely any work done, and then my machine hung up, I had to reboot, and the way our harness works you have to start *completely from scratch* -- there is no way to start from the beginning. /rant off I'm with you on that. I've always wanted to have RunSuite take a list of suites, not just one. Rant and you shall recieve? Attached is a patch which does the above. It turned out to be a little more difficult than I thought, because the harness actually does some setup in getSuiteProperties (bad harness! bad!), so I couldn't just override the value of the suites field. But then again turned out to not be so bad, since getSuiteProperties already included functionality to load a suite definition from the current directory, so I just needed to write out a new adhoc suite definition. In other news, RunSuite can read a suite definition from the current directory. Did anyone else know that? I didn't. Anyway, makes this patch sort of moot. But with the patch its even more direct, just enter the suites you want to run on the command line. cheers, andrew
Re: !$!% derbyall
Thanks for your tips and concern, all. Mike: I remember that it used to take me four hours a few weeks ago, and I didn't have these CPU issues, but this latest run broke all records. My laptop is pretty good -- I upgraded specifically so I could run derbyall on it and keep working, but for some reason yesterday it was just killing me. When I ran Task Manager, it showed java.exe taking up 80-90% of CPU, and when certain tests ran (stress.multi) it went up to 100%. Kathey: I run Disk Defragmenter every day... (except yesterday, as I was already in trouble before it kicked off automatically, so I killed it) [PC Information] OS VersionMicrosoft Windows XP Professional 5.1.2600 Service Pack 2 CPU Intel(R) Pentium(R) M processor 2.00GHz Memory2048MB RAM Hard Disk Capacity60,011,642,880 [Byte] 55.890 [GB] Hard Disk Free Space Capacity 29,242,060,800 [Byte] 27.234 [GB] IDE Device 1 HTS726060M9AT00 (I got this disk particularly because it was reasonably fast) David Mike Matrigali wrote: David W. Van Couvering wrote: rant on Sorry, but it is so frustrating. I started a derbyall run at 9 this morning, and it was still running this evening. My CPU was at 100%, I could get barely any work done, and then my machine hung up, I had to Out of curiosity what are the specs on the machine you are running. I run on a 2 year old laptop, running XP - 1700 mhz, sane build. My latest run against sun jvm 1.4.2 against 10.1 was 4 hours - and I hardly ever see 100% cpu (I realize trunk has more tests, just don't have those results handy). It is likely insane build will run faster.
Re: Patch for running RunSuite with a list of suites (was Re: !$!% derbyall)
Great, thanks.
I'll try your patch out. Is this something you'll commit if it works
for you (and me)?
David
Andrew McIntyre wrote:
On 4/13/06, David W. Van Couvering [EMAIL PROTECTED] wrote:
Can anyone tell me how I find out, if derbyall or any suite goes down
half-way through, what suites have run so far, and which ones have
passed and which ones have failed?
In the directory where you were running the tests will be a file
{suite}.sum, which contains a running list of all the tests that had
run so far. you'll need to take a look at the order of the suites in
derbyall to determine where you were, exactly. But just search for
'Failed' in the sum file and you'll find the diff of any failures that
had already occurred.
andrew
Re: !$!% derbyall
Thanks, Dyre, good info. I was running with 393331 I'll try nice, I was surprised to find it available on Cygwin. David [EMAIL PROTECTED] wrote: David W. Van Couvering [EMAIL PROTECTED] writes: Thanks for your tips and concern, all. Mike: I remember that it used to take me four hours a few weeks ago, and I didn't have these CPU issues, but this latest run broke all records. My laptop is pretty good -- I upgraded specifically so I could run derbyall on it and keep working, but for some reason yesterday it was just killing me. Do you happen to know the exact revision you were running? From http://www.multinet.no/~solberg/public/Apache/Derby/index.html/derbyall_history.html it looks like r392019 and r392564 took a long time, up to 2.5 times the baseline on some platforms. A general observation is that the running time seems to increase with the number of failures. I try to run derbyall with nice. It usually doesn't take much longer, AND my machine is usable, even during stress.multi.
Derby nightly testrun was killed and is disable (was Re: zero failures on jdk 1.6)
One of our QA guys in Norway (Bjorn) killed a Derby test run last night as we were running out of disk space (I saw an email to this effect on an internal list). It's Easter holiday in Norway and most everybody's away for the rest of the week... I talked to him this morning and he isn't sure *what* Derby test he killed, but he has now disabled the night tests until everyone gets back. So I'm not sure of the validity of this jdk16 test run... Thanks, David Rick Hillegas wrote: This is good news. I think we're ready now to wire the jdbc40 suite into derbyall (it should only run on jdk16). BTW, my last derbyall on jdk14 reported that it ran 645 tests. Regards, -Rick Andrew McIntyre wrote: On 4/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: *Derby* 393268/2006-04-11 19:45:56 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 0647647 0 100.00% SunOS-5.10_i86pc-i386 Hey - zero failures on jdk 1.6! Yay! One thing though - the number of tests run is incorrect. If you tally up the total tests run from the individual suites, you get 776, not 647. I guess the harness has forgotten how to count? ;-) Actually, I think its not counting the number of tests in the nist suite or something - the difference (129) is suspiciously close to the number of tests in the nist suite, and the nist suite is the only one that runs with useprocess=false... andrew
!$!% derbyall
rant on Sorry, but it is so frustrating. I started a derbyall run at 9 this morning, and it was still running this evening. My CPU was at 100%, I could get barely any work done, and then my machine hung up, I had to reboot, and the way our harness works you have to start *completely from scratch* -- there is no way to start from the beginning. /rant off If I weren't so busy trying to get some this i18n work completed I would do the work of defining a smaller MATS. Instead I must sigh and restart the thing all over again. Hopefully by tomorrow morning it will be completed. I have two other patches in the queue waiting for machine resources so I can run derbyall for them as well... David
Re: Newcomer component
That's a good point, but if we put a link to the JIRA filter for newcomers on the newcomer Wiki page it shouldn't be too bad... When entering a JIRA bug, the checkboxes are very easy to see and easier to select than components, so that's a plus. That and it is more accurate, IMHO. The question I have, is how hard it is to convert bugs with Newcomer component to bugs with the Newcomer checkbox... David Andrew McIntyre wrote: On 4/10/06, David W. Van Couvering [EMAIL PROTECTED] wrote: It seems to me that Newcomer should be a flag, not a component. I think of components as parts of the code. Is it possible to convert this to a flag? That's fine with me, although then you don't have that nice Newcomer listing on the front page of the Derby JIRA. Having to go through the web interface to create a filter for the newcomer flag, or even get to a global filter, puts quite a few steps between the newcomer and issues that they could work on. I don't really have strong feelings either way, though. andrew
Re: Newcomer component
If you can't do a permanent link to a filter, then let's keep it as it is... David Andrew McIntyre wrote: On 4/11/06, David W. Van Couvering [EMAIL PROTECTED] wrote: That's a good point, but if we put a link to the JIRA filter for newcomers on the newcomer Wiki page it shouldn't be too bad... Except I don't think you can't get a permanent link to a saved JIRA filter. The question I have, is how hard it is to convert bugs with Newcomer component to bugs with the Newcomer checkbox... That part is easy, with the bulk change operation. andrew
Message ids with no messags
I wrote a quick test, which I'll check in, which looks for duplicate message ids in SQLState.jaa and message ids in SQLState.java that do not have a matching message in messages_en.properties. Attached is the output. I wonder how many of these ids are actually used, which is a guarantee that the user will get UNKNOWN when they get an exception. I'm going to pare out these message ids and see what kind of compile errors I get... I think this will be a good test to add to derbyall... David .ERROR: message id 22005 occurs more than once in SQLState.java FAIL - Unable to find message id X0RQC.S in messages_en.properties FAIL - Unable to find message id 42X70 in messages_en.properties FAIL - Unable to find message id XBM03.D in messages_en.properties FAIL - Unable to find message id X0X0B.S in messages_en.properties FAIL - Unable to find message id XJ05A.S in messages_en.properties FAIL - Unable to find message id 42Y81 in messages_en.properties FAIL - Unable to find message id X0X0C.S in messages_en.properties FAIL - Unable to find message id XSDAM.S in messages_en.properties FAIL - Unable to find message id XBAED.S in messages_en.properties FAIL - Unable to find message id XSDI0.T in messages_en.properties FAIL - Unable to find message id 42X95 in messages_en.properties FAIL - Unable to find message id XSDAN.S in messages_en.properties FAIL - Unable to find message id 25504 in messages_en.properties FAIL - Unable to find message id X0RQ4.C in messages_en.properties FAIL - Unable to find message id 42X99 in messages_en.properties FAIL - Unable to find message id X0Y82.S in messages_en.properties FAIL - Unable to find message id 42Y31 in messages_en.properties FAIL - Unable to find message id X.C.4 in messages_en.properties FAIL - Unable to find message id 42X21 in messages_en.properties FAIL - Unable to find message id XJ024.S in messages_en.properties FAIL - Unable to find message id X0X08.S in messages_en.properties FAIL - Unable to find message id XBCA3.S in messages_en.properties FAIL - Unable to find message id X0RQ5.S in messages_en.properties FAIL - Unable to find message id XJ038.U in messages_en.properties FAIL - Unable to find message id 44X02.U in messages_en.properties FAIL - Unable to find message id X0Y81.S in messages_en.properties FAIL - Unable to find message id 42703 in messages_en.properties FAIL - Unable to find message id X0X0D.S in messages_en.properties FAIL - Unable to find message id XSLA9.D in messages_en.properties FAIL - Unable to find message id XSDFG.S in messages_en.properties FAIL - Unable to find message id X0Y53.S in messages_en.properties FAIL - Unable to find message id XSTA3.S in messages_en.properties FAIL - Unable to find message id X0X09.S in messages_en.properties FAIL - Unable to find message id 44X03.U in messages_en.properties FAIL - Unable to find message id X.C.5 in messages_en.properties FAIL - Unable to find message id XBAEB.S in messages_en.properties FAIL - Unable to find message id 42Y87 in messages_en.properties FAIL - Unable to find message id 42Z12 in messages_en.properties FAIL - Unable to find message id X0RQ3.C in messages_en.properties FAIL - Unable to find message id XSTB4.M in messages_en.properties FAIL - Unable to find message id X0X93.S in messages_en.properties FAIL - Unable to find message id 42Y21 in messages_en.properties FAIL - Unable to find message id X0RQ6.S in messages_en.properties FAIL - Unable to find message id 44X16.U in messages_en.properties FAIL - Unable to find message id X0RQB.S in messages_en.properties FAIL - Unable to find message id XBAEA.S in messages_en.properties FAIL - Unable to find message id XSAX1 in messages_en.properties FAIL - Unable to find message id X0RQ2.C in messages_en.properties FAIL - Unable to find message id X0Y75.S in messages_en.properties FAIL - Unable to find message id 44X04.U in messages_en.properties FAIL - Unable to find message id 42X71 in messages_en.properties FAIL - Unable to find message id 42Y86 in messages_en.properties FAIL - Unable to find message id X0X0A.S in messages_en.properties FAIL - Unable to find message id 0100C in messages_en.properties FAIL - Unable to find message id close.C.1 in messages_en.properties FAIL - Unable to find message id X0Y65.S in messages_en.properties FAIL - Unable to find message id 44X17.U in messages_en.properties FAIL - Unable to find message id XD001.S in messages_en.properties FAIL - Unable to find message id 42X81 in messages_en.properties FAIL - Unable to find message id 28000 in messages_en.properties FAIL - Unable to find message id XCL32.S in messages_en.properties FAIL - Unable to find message id XJ999.S in messages_en.properties FAIL - Unable to find message id XJ04A.S in messages_en.properties FAIL - Unable to find message id 42Y89 in messages_en.properties FAIL - Unable to find message id XBM04.D in messages_en.properties FAIL - Unable to find message id XSAX0 in messages_en.properties FAIL - Unable to find message id 42Z9C
Newcomer component
It seems to me that Newcomer should be a flag, not a component. I think of components as parts of the code. Is it possible to convert this to a flag? Thanks, David
Re: Upgrade Testing - more tests needed for 10.2 ?
Thanks, Deepa. Given the importance of this feature on Derby's dependability and ease of use, A Wiki page on this would be wonderful, if anyone is so inspired. David Deepa Remesh wrote: Is there a document for developers somewhere that explains the kinds of changes that impact upgrade, and how you go about writing a test an upgrade-impacting change? I'm a bit mystified myself right now... (although I'm pretty darn sure i18n changes in the client don't impact upgrade :) ). I don't think there is a document which summarizes the kinds of changes that may impact upgrade. I think this article helps: http://db.apache.org/derby/papers/versionupgrade.html. Other than that, the various discussions are spread out in the mails. For adding tests, please look at the case* methods in org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester. I'll try to add information about the test to a Wiki page. Thanks, Deepa
Re: Regression Test Failure! - TinderBox_Derby 392254 - Sun DBTG
I'm assuming these tests pass on JDK 1.6? It is a little disconcerting that they hang, it would be nice to find out why. David Kathey Marsden wrote: [EMAIL PROTECTED] wrote: The client jdbc/checkDataSource tests seem to have a problem with jdk 1.5. I ran and they do seem to hang on jdk 1.5. I had run the tests 50 times on jdk 1.42, I didn't see the hang. I think I will approach this by disabling checkDataSource and checkDataSource30 on jdk 1.5 until this issue is resolved unless someone has seen issues on another jvm. Does that sound ok? Kathey [Auto-generated mail] *TinderBox_Derby* 392254/2006-04-07 13:23:10 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2650648 0 244.42% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-392254.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/392254.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/392254.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Commented: (DERBY-615) Get 95% of functional tests running under the SecurityManager when running derbyall
Wow, great news, Dan! I'll have to mosey over and see what the security properties file looks like these days, I hope it's not too full of permissions... David Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-615?page=comments#action_12373683 ] Daniel John Debrunner commented on DERBY-615: - As of 2006/0407 95.4% of tests in derbyall run under the security manager!! See http://wiki.apache.org/db-derby/SecurityManagerTesting I think I will keep this bug open until every test that does not run under the security manager has an open Jira issue or valid reason in its _app.properties file. Get 95% of functional tests running under the SecurityManager when running derbyall --- Key: DERBY-615 URL: http://issues.apache.org/jira/browse/DERBY-615 Project: Derby Type: Test Components: Security, Test Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner Fix For: 10.2.0.0 Ensure that running derbyall tests all Derby's functionality works with a security manager and a correctly, minimally configured policy file. By minimally I mean just the fewset set of permissions required, hopefully in-line with the documentation. E.g. a policy file that allowed all permissions would work but would not be a good test of Derby. See http://wiki.apache.org/db-derby/SecurityManagerTesting
updateRow() behavior difference between client and embedded drivers - which is right?
In inspecting the exceptions across client and embedded drivers, I noticed that in the method updateRow(), if the current row has not been modified, the client throws an exception. However, the embedded driver returns without taking any action and does not throw an exception. The JavaDoc for updateRow() says nothing about what behavior is expected. Does anyone know which one is correct? Given a choice, I would prefer the more forgiving implementation in the embedded driver. An alternate is to throw a SQLWarning rather than a SQLException. Once I have a better sense of what the right behavior is, I can log a bug about this and attach it to our list of inconsistencies. Thanks, David
Re: Regression Test Failure! - TinderBox_Derby 391903 - Sun DBTG
The checkDataSource failures are a bit disconcerting. Does anyone have any ideas for the cause? David [EMAIL PROTECTED] wrote: [Auto-generated mail] *TinderBox_Derby* 391903/2006-04-06 07:22:18 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2647645 0 243.63% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-391903.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/391903.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/391903.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Preparing for potential Google Summer of Code
Hi, all. It is possible that Google will want to do another Summer of Code this year. Google pays students to join open source communities as interns for the summer. While Google uses this as an opportunity to identify the best and brightest up-and-coming coders, it is also a useful opportunity for open source projects to get issues addressed, new avenues explored and bugs fixed - and potentially to recruit new community members and gain a raised public profile. It would be great if Apache Derby could participate in this. To do this we need to be ready with an answer to the question what would one or more students do if they joined Derby for three months? It's important to be prepared. With the Summer of Code site opens up, we need to register our community, identify a contact point for the project and mentors for the students and a list of potential projects. Last summer there were only about 48 hours to respond from the announcement before the program was fully subscribed. What I'd like to suggest is the following: - Who would like to be the contact point? I am thinking Jean Anderson, as our community liason extraordinaire. - Put together a Wiki page with potential projects and mentors for each project. It would be great to have this regardless, as a way to encourage participation. If this sounds good, I can start the Wiki page, and then anyone who has an idea for a project and/or is willing to mentor can update that page. David
Re: Preparing for potential Google Summer of Code
You're right Susan, thanks. I'd be happy to volunteer for this role. David Susan Cline wrote: --- David W. Van Couvering [EMAIL PROTECTED] wrote: Hi, all. It is possible that Google will want to do another Summer of Code this year. Google pays students to join open source communities as interns for the summer. While Google uses this as an opportunity to identify the best and brightest up-and-coming coders, it is also a useful opportunity for open source projects to get issues addressed, new avenues explored and bugs fixed - and potentially to recruit new community members and gain a raised public profile. It would be great if Apache Derby could participate in this. I think this is a great idea, and I hope we participate in it. [ snip ] What I'd like to suggest is the following: - Who would like to be the contact point? I am thinking Jean Anderson, as our community liason extraordinaire. Instead of suggesting who might be appropriate for this, how about if we ask for a volunteer, instead? Jean may be willing to take this on, but I think in the spirit of scratching your own itch it's feels better to volunteer for a task without feeling like it may have been assigned to you. Susan
Re: Upgrade Testing - more tests needed for 10.2 ?
Thanks for this important effort, Deepa. Is there a document for developers somewhere that explains the kinds of changes that impact upgrade, and how you go about writing a test an upgrade-impacting change? I'm a bit mystified myself right now... (although I'm pretty darn sure i18n changes in the client don't impact upgrade :) ). David Deepa Remesh wrote: Hi, I have been working on making the upgrade tests run as part of derbyall and noticed that there is only one test (caseReusableRecordIdSequenceNumber) which has been specifically added for 10.2. The javadoc comment for UpgradeTester class lists what is tested for 10.1. I think we need a similar list for 10.2 and maybe, more tests for any new features. Andrew mentioned he is working on getting the jars in the repository and I am working on using these repository jars and defining a standard way to run the test so that it can run as part of derbyall. I plan to document this in readme/building.txt once everything is in place. For now, to run upgrade tests, we need to pass in the location of previous version jar (10.1.2.1) as follows: java -Djvmflags=-DderbyTesting.oldJarLocation=location of 10.1 jars org.apache.derbyTesting.functionTests.harness.RunTest upgradeTests/Upgrade_10_1_10_2.java NOTE: Test runs with jar files in the classpath. It does not run with classes folder. Please feel free to add more 10.2 tests to UpgradeTester while rest of the testing infrastructure is being set up. Thanks, Deepa
Re: Preparing for potential Google Summer of Code
For your background information and to give you some ideas, here is the link to last year's summer of code http://code.google.com/summerofcode.html David W. Van Couvering wrote: Hi, all. It is possible that Google will want to do another Summer of Code this year. Google pays students to join open source communities as interns for the summer. While Google uses this as an opportunity to identify the best and brightest up-and-coming coders, it is also a useful opportunity for open source projects to get issues addressed, new avenues explored and bugs fixed - and potentially to recruit new community members and gain a raised public profile. It would be great if Apache Derby could participate in this. To do this we need to be ready with an answer to the question what would one or more students do if they joined Derby for three months? It's important to be prepared. With the Summer of Code site opens up, we need to register our community, identify a contact point for the project and mentors for the students and a list of potential projects. Last summer there were only about 48 hours to respond from the announcement before the program was fully subscribed. What I'd like to suggest is the following: - Who would like to be the contact point? I am thinking Jean Anderson, as our community liason extraordinaire. - Put together a Wiki page with potential projects and mentors for each project. It would be great to have this regardless, as a way to encourage participation. If this sounds good, I can start the Wiki page, and then anyone who has an idea for a project and/or is willing to mentor can update that page. David
Setting patch available flag?
I am noticing a number of patches being attached to JIRA, but when I do a quick query to see what items have a patch available (by looking for the checkbox), only one shows up. A gentle reminder to set that checkbox when you upload a patch! :) David
Re: Setting patch available flag?
Thanks, John, that was it. I tried to edit Satheesh's filter but I can't save it, only save as new... David John Embretsen wrote: Wednesday, April 5, 2006, 6:24:20 PM CET, David W. Van Couvering wrote: I am noticing a number of patches being attached to JIRA, but when I do a quick query to see what items have a patch available (by looking for the checkbox), only one shows up. A gentle reminder to set that checkbox when you upload a patch! :) I think the global JIRA filter Derby: JIRA issues with patch available by Sateesh needs to be updated because of Andrew's change a few days ago (the 'Patch Available' checkbox was changed from Other Info to Derby Info). When I search using my own patch available filter, I get 19 issues... So I don't think committers and reviewers are out of work quite yet ;)
Re: Upgrade tests and jars in the repository
I often have multiple checkouts on my machine, one for something I'm
running derbyall, one for something I'm actively working on, and one for
patches I need to evaluate.
I don't think it's crucial, but is there a way to have a single set of
jar files that can be shared across multiple code checkouts? Is that
what you are making possible by changing the svn:externals property?
David
Andrew McIntyre wrote:
I've been thinking about how to make the Derby jars accessible to the
upgrade tests, and I don't think there's going to be a better way
other than to put the jars into the repository. But, I don't think we
should check them into the code tree. I think that we should create a
new tree at the same level as code, site, and docs, and call it jars.
In this tree will be directories containing the Derby jars from the
official releases in directories by version. E.g.:
derby
+ code
+ jars
+ 10.1.1.0
+ 10.1.2.1
Then, we can map the specific jars we need into the code tree using
the svn:externals property to a specific location in the code tree, I
suggest tools/testing/derby/{version}. This way, we prevent lots of
copies of the derby jars from multiplying in the repository as
branches are created and tagged. Yeah, I know, they're lazy copies not
real copies, but it seems a lot cleaner way to do it to me. It also
makes changing the jars in your view as simple as changing/adding a
property if you want to test against a different set of jars.
This does mean that you'll need to download a set of Derby jars with
each new checkout, adding to the space, time, and bandwidth
requirements to checkout. As an alternative, I had also thought about
having Ant grab the jars on demand, but that seemed less intuitive
than having svn grab them automatically. And, we do want everybody
running the upgrade tests, right?
Deepa, does this sound like a good plan to you? Will the upgrade tests
be able to locate the jars in the location above? That's the next
question to answer and I'll start looking at how the tests can locate
the jars based on the execution environment.
andrew
Re: Upgrade tests and jars in the repository
OK, I think I agree that reducing configuration wins out over space (up to a point). Another reason to keep our jar files small! :) David Andrew McIntyre wrote: On 4/5/06, David W. Van Couvering [EMAIL PROTECTED] wrote: I often have multiple checkouts on my machine, one for something I'm running derbyall, one for something I'm actively working on, and one for patches I need to evaluate. I don't think it's crucial, but is there a way to have a single set of jar files that can be shared across multiple code checkouts? Is that what you are making possible by changing the svn:externals property? No, what svn:externals allows you to do is have a single, external source for a directory in your hierarchy. Then multiple branches do not each carry copies of the files, they are sourced from the external location when you perform a checkout. Sharing a single set across checkouts would necessitate configuring a master location for the files, and I think what we want for the upgrade tests is a zero configuration policy so that automated tests can be run without any additional setup. I suppose we could require an extra step to checkout the jars or configure a master location for the jars for the upgrade tests before a full build-and-test on a new checkout can complete, but I tend to prefer less configuration, not more. :-) andrew
Putting all messages in messages.properties?
I would like to understand what resistance there might be to putting all messages in the single properties file, messages_XX.properties, and using a build script to copy over the appropriate messages for the client. Right now messages that are deemed client only are put manually into clientmessges.properties. But I am discovering this is a challenge because (a) it's hard to ensure uniqueness across the two files and (b) you never know when a message you put into the client file may actually be useful later on to a class on the engine side. The potential drawback is that the client-specific messages are now in engine-side properties files, which can increase the overall footprint of derby.jar. My estimate is there will be no more than 200 messages (MAX) that are client-specific, and possibly quite fewer -- I am finding many opportunities for reuse of existing messages. Thoughts on this are much appreciated. David
Re: Putting all messages in messages.properties?
I think perhaps you misunderstand. I know nothing about stored procedure calls to get messages. I have a properties file called clientmessages.properties that has the messages used by the network client code, and they are loaded directly as a resource. I have updated splitmessages.java in the build directory to copy messages from messages_XX.properties over to clientmessages_XX.properties (for each locale). What I'm doing right now is if there are messages that are new for the client code and not currently being used by the engine, I am manually adding those to clientmessages.properties, and splitmessages is then appending to this. What I am suggesting is that I put *all* messages in messages.properties, and the splitmessages.java copies them all over. No manually adding messages to clientmessages.properties any more. It will likely increase the size of derby.jar by ~200 messages x ~80 bytes each or 16K. The derbyclient.jar will increase by 16K also (this is regardless of what approach we choose), but this is offset by the fact that hardcoded strings are now being removed from the Java code. David Kathey Marsden wrote: David W. Van Couvering wrote: I would like to understand what resistance there might be to putting all messages in the single properties file, messages_XX.properties, and using a build script to copy over the appropriate messages for the client. How much would this increase the size of client and server? I had always thought that if it didn't cause too much bloat, this would be a good solution, because it might also potentially mean we could get rid of the horrible stored procedure call for client messages.I have always been big fan of build based code sharing. All the other strategies seemed awfully cumbersome to users and developers to me. Kathey
Re: [jira] Commented: (DERBY-1152) Failures in sysinfo and sysinfo_withproperties induced by classpath wiring
If I ever implement the classloading scheme for code sharing, I would need to find out where the current class was loaded from, and I would need the same permissions. Although maybe I can take advantage of the work sysinfo is already doing. David Andrew McIntyre (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1152?page=comments#action_12373171 ] Andrew McIntyre commented on DERBY-1152: Sorry for the late reply, but yes, I believe adding these permissions to the test policy is ok. There are only two places in the code we try to get the classpath, sysinfo and the client trace code, both handle security exceptions, and I think it's unlikely that we'll need to get the contents of the classpath elsewhere, but you never know. Maybe we should mark this bug number in the policy file for future reference in case anyone wonders why these permissions were added. I can take care of that as I follow up on DERBY-622. Failures in sysinfo and sysinfo_withproperties induced by classpath wiring -- Key: DERBY-1152 URL: http://issues.apache.org/jira/browse/DERBY-1152 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Rick Hillegas Assignee: Bryan Pendleton Fix For: 10.2.0.0 Attachments: derby-1152-looser-policy.diff If you wire your classpath together out of the compiled classtree and the checked-in jars, you get the following error in the sysinfo and sysinfo_withproperties tests. You don't see this error if you run against the built Derby jar files: 15d14 Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read) 43d41 Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read) 72d69 Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read) Test Failed.
Re: Putting all messages in messages.properties?
The client messages.properties file will only have messages used by the client. In particular, it will have all messages whose ids start with XJ, as well as a select list which are specified in splitmessages.java. So you won't have the entire 71K properties file on the client side. David Satheesh Bandaram wrote: David W. Van Couvering wrote: The potential drawback is that the client-specific messages are now in engine-side properties files, which can increase the overall footprint of derby.jar. My estimate is there will be no more than 200 messages (MAX) that are client-specific, and possibly quite fewer -- I am finding many opportunities for reuse of existing messages. How about client footprint? If we have a single message file that included all server and client messages, wouldn't that increase client footprint a lot? Potentially there could be multiple copies of the message files in CLASSPATH to support different languages? derbyLocale_fr, for example, seems to be 71K in size. Satheesh Thoughts on this are much appreciated. David
Re: Putting all messages in messages.properties?
I thought about that. The issue is that you never know when a client only message may end up being useful for the server. I'm worried that a developer wouldn't know to take a message of the exclude from server list and at runtime the message wouldn't be found. David Satheesh Bandaram wrote: Right... I was just reading splitmessages.java. Could this be enhanced to remove client only messages from the server messages? Satheesh On 4/4/06, *David W. Van Couvering * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The client messages.properties file will only have messages used by the client. In particular, it will have all messages whose ids start with XJ, as well as a select list which are specified in splitmessages.java . So you won't have the entire 71K properties file on the client side. David Satheesh Bandaram wrote: David W. Van Couvering wrote: The potential drawback is that the client-specific messages are now in engine-side properties files, which can increase the overall footprint of derby.jar. My estimate is there will be no more than 200 messages (MAX) that are client-specific, and possibly quite fewer -- I am finding many opportunities for reuse of existing messages. How about client footprint? If we have a single message file that included all server and client messages, wouldn't that increase client footprint a lot? Potentially there could be multiple copies of the message files in CLASSPATH to support different languages? derbyLocale_fr, for example, seems to be 71K in size. Satheesh Thoughts on this are much appreciated. David
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
I think it might be good to document these as part of the release notes or release documentation. I don't have strong feelings about this, but it seems like a good idea. David Satheesh Bandaram wrote: Hi David, On 4/3/06, *David W. Van Couvering* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Satheesh Bandaram wrote: This is a very good list... Thanks for putting this together. Should we consider documenting some of the important items once the Wiki page is more firmed up? Are you saying some of these interfaces, while supported, are not documented? See Jeff Levitt's comment, I would argue that anything undocumented must be marked as a Private interface until documented. No, I meant to ask if the table of Derby interfaces and their stability levels that you are cooking up should be documented? Instead of documenting the whole table, I was asking may be we could identify important interfaces and their stability levels. Some more items to include: 1) Trace outputs. Many modules have tracing support. Should this be marked PRIVATE? Yes, I can add that. 2) Errorlog contents. UNSTABLE? I had derby.log format, isn't that the same thing? Yes... It is. I missed it in the list. 3) Query plan output as displayed by RUNTIMESTATISTICS. UNSTABLE? If it's documented, Unstable seems good. If it's not documented, then we should mark it as Private. We do document output of RUNTIMESTATISTICS and how to analyse it in Tuning guide. 4) Derby properties. I think Documented properties should be marked STABLE. Undocumented properties are UNSTABLE. Undocumented properties should probably be marked Private, by their very nature they can't be Unstable since they're not documented. Guess PRIVATE is better for undocumented properties. You are right... Satheesh David Satheesh On 3/31/06, *David W. Van Couvering* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I've updated the Wiki page to reflect some of this discussion and my sense of where things are ending up. You can use the diff mechanism of the Wiki to see what's changed. David Kathey Marsden wrote: Rick Hillegas wrote: I think you may have already addressed the following issues in email, but I don't see the results rolled onto the wiki page. Please pardon my nitpicking. This kind of discussion turns me into a tiresome, pedantic Mr. Hyde: 1) The cardinal rule. I recommend wordsmithing the cardinal rule: The goal is to allow any application written against the public interfaces an older version of Derby can run, without any changes, against a newer version of Derby. To me the following formulation reads better This is our goal: An application which ran against Derby yesterday will run against a higher version of Derby tomorrow. I prefer the original wording with only a small grammatical change to instead of can. The goal is to allow any application written against the public interfaces an older version of Derby to run, without any changes, against a newer version of Derby. It is good to think past tomorrow. But is that really the cardinal rule? Maybe we really mean this: This is our goal: An application which runs against a Derby release today will also run tomorrow against the next minor release. I do not like this wording .It might seem to imply that you cannot skip minor releases e.g. go from 10.l to 10.3. It might also seem to imply that you cannot run a 10.1 client with a 10.3 server for example. We strive to minimize churn for applications migrating to the next major release of Derby. However these migrations may entail application changes. The way major releases are described in this mail is the way I have seen them in the past, where we break upgrade, client/server compatibility and many other things and it is like switching to a new product, but I want better for the users of Derby 10 when they switch to 11. I still need to think a lot about the whole major version boundary thing. It seems like we like solaris
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
I agree that you can't really advertise a new feature as really available unless it's documented, and that in this scratch-your-itch world, this would seem to be something that the person writing the feature would be motivated to do. I think having a requirement that some specification is required before an interface is considered public is worth considering. Of course, the other people who may be itching to document a feature are those who want to use it, so I could imagine it being a collaborative effort. I can add a note to the effect that no interface can be considered a public interface (e.g. Stable, Unstable or Standard) unless it is documented in the user documentation. Would this get the point across? David Jeff Levitt wrote: Hi David, Yes I thinnk thats what I'm trying to say. Of course something can be implemented and not documented, or the other way around, but my sense is that we are trying to make acontract here for ourselves, and with our users, and I think that if part of that contract is to tell our users that what they see in the doc is fact, then we should strive to always make that true. That means a new contribution would not be accepted unless it included corresponding documentation. If we add a new function then either a patch to the DITA source referencing that function is included, or at the very least a full function spec is submitted so that documentation can be written by someone else. The bottom line would be that documentation would be considered as important as codeline itself; quality considerations would include documentation, just as proper code consistency and standards are required. Most contributors are not documentation specialists, so maybe it is too much to ask, but I think if we are telling users to accept the doc as the final word, then we need to have some sort of MINIMUM doc contribution requirement. What do other people think? --- David W. Van Couvering [EMAIL PROTECTED] wrote: Hi, Jeff. I've been quiet on this comment because I didn't fully understand it. I *think* what you're saying is that an interface can not be considered Stable or Unstable unless it's actually documented. Is that right? David Jeff Levitt wrote: From a documentation perspective, I think if we are going to say on this page that items are stable AS DOCUMENTED in the user documentation, then we also need to put in some sort of requirement on this page that says any changes made to the stability of an item MUST be documented as well in order to be committed an considered stable. Its not stable if its not documented and we are telling people that it is stable as documented. Agreed? I think this is something that would be good to put in to make sure that developers understand the importance of documenting their work, whether its something new or a change to something that exists, and that its not just going to magically show up in the documentation if they put it in the code (unless its javadoc) :) --- David W. Van Couvering [EMAIL PROTECTED] wrote: Thanks for your comments, Kathey, and yes, it can definitely wait a week. It was just so quiet that I thought I'd do a ping and see if there was more to come from everyone. Responses below... Kathey Marsden wrote: I wish I had more time to look at this but I think that I would add these things. - In general any documented behaviour is a stable interface, unless specifically documented here or in the documentation as unstable. I'm not sure how to handle this. What does it mean to incompatibly change documented behavior? Usually the behavior is in relation to a given interface. So perhaps in our definition of what it means to incompatibly change an interface means you can't change the documented behavior of that interface (e.g. the contract of that interface). I think it's also fair to say that unless explicitly called out in the table as otherwise, one can assume a publicly documented interface is Stable. - Derby will at a minimum negotiate down to the lower interface revision level: - When different versions of Derby client and server are used together (in the same or different JVM's) - When different jvm versions are used on client and server. I think this is a solution that provides a guarantee of stability to the client/server interfaces. I can add this as a note, however. I think by calling out the *specific* interfaces that the client depends upon (DRDA, metadata procedures, system stored procedures, ???) and marking them as Stable or Private Stable is a Really Good Idea in our attempts to provide the guarantee of client/server compatiblity. Note, for example, some of us newbies changing the metadata procedures willy nilly because we were unaware of the impact on compatibility. Having these called out will make us all more conscious of what we can and can't do
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Satheesh Bandaram wrote: This is a very good list... Thanks for putting this together. Should we consider documenting some of the important items once the Wiki page is more firmed up? Are you saying some of these interfaces, while supported, are not documented? See Jeff Levitt's comment, I would argue that anything undocumented must be marked as a Private interface until documented. Some more items to include: 1) Trace outputs. Many modules have tracing support. Should this be marked PRIVATE? Yes, I can add that. 2) Errorlog contents. UNSTABLE? I had derby.log format, isn't that the same thing? 3) Query plan output as displayed by RUNTIMESTATISTICS. UNSTABLE? If it's documented, Unstable seems good. If it's not documented, then we should mark it as Private. 4) Derby properties. I think Documented properties should be marked STABLE. Undocumented properties are UNSTABLE. Undocumented properties should probably be marked Private, by their very nature they can't be Unstable since they're not documented. David Satheesh On 3/31/06, *David W. Van Couvering* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I've updated the Wiki page to reflect some of this discussion and my sense of where things are ending up. You can use the diff mechanism of the Wiki to see what's changed. David Kathey Marsden wrote: Rick Hillegas wrote: I think you may have already addressed the following issues in email, but I don't see the results rolled onto the wiki page. Please pardon my nitpicking. This kind of discussion turns me into a tiresome, pedantic Mr. Hyde: 1) The cardinal rule. I recommend wordsmithing the cardinal rule: The goal is to allow any application written against the public interfaces an older version of Derby can run, without any changes, against a newer version of Derby. To me the following formulation reads better This is our goal: An application which ran against Derby yesterday will run against a higher version of Derby tomorrow. I prefer the original wording with only a small grammatical change to instead of can. The goal is to allow any application written against the public interfaces an older version of Derby to run, without any changes, against a newer version of Derby. It is good to think past tomorrow. But is that really the cardinal rule? Maybe we really mean this: This is our goal: An application which runs against a Derby release today will also run tomorrow against the next minor release. I do not like this wording .It might seem to imply that you cannot skip minor releases e.g. go from 10.l to 10.3. It might also seem to imply that you cannot run a 10.1 client with a 10.3 server for example. We strive to minimize churn for applications migrating to the next major release of Derby. However these migrations may entail application changes. The way major releases are described in this mail is the way I have seen them in the past, where we break upgrade, client/server compatibility and many other things and it is like switching to a new product, but I want better for the users of Derby 10 when they switch to 11. I still need to think a lot about the whole major version boundary thing. It seems like we like solaris will be set at the same major version for a very long time. As I stated before I think for some things a time based approach seems most appropriate. You can expect your client to work with new servers for the next five years for example. We should not just leave users trying to figure out how to upgrade their server and all of their clients all in one night because we bumped from 10 to 11. If we expect upgrade=true to work from 10 to 11 we should expect client/server compatibility to be maintained as well. So either the time based approach or for major versions have compatibility with the previous and next major versions.For example with Derby 11 you can use Derby 10 or Derby 12, but not Derby 13. 2b) Our DRDA implementation may incorrectly transport datatypes not recognized by DRDA. Conforming to the DRDA spec may mean removing this transport capability and breaking applications which select the unsupported datatypes. Protocol has an impact on client JDBC, SQL and even the ability to connect and those cannot be broken. Client and server can have version dependent behaviour to mitigate the change to DRDA compliant behavior. 3) Client/server compatibility. I would expect to find these rules spelled out
Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)
I reviewed such a document that was contributed by Jeff Levitt as part of 10.1, see http://db.apache.org/derby/docs/10.1/ref/rrefexcept71493.html In my latest ref of the interface table, I have marked those SQL States that are based on the SQL Standard as Standard, and those SQL States that are specific to Derby as Unstable. David Andreas Korneliussen wrote: David W. Van Couvering wrote: This is an example where we find our code throwing the wrong SQL State, but are we allowed to fix it? Lance says yes. Others providing support for customers say (I think) no. This ties into the discussion about the stability classification for SQL States. If we mark it as Stable, then we can't change this. If we mark it as Unstable, then we can. Comments, thoughts? Is there a document for Derby with error conditions and expected SQL state ? If there is no such document, one cannot claim that the classification for SQL state is Stable. In general, I do not think any interface can be marked as stable, unless documented. Even if we do have a document of expected error conditions and expected SQL state, we should be allowed to make bugfixes if the implementation is incorrect w.r.t the document / specification. Andreas
Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)
And, yes, I think we have generally agreed it's OK to fix a bug if Derby is incorrect in terms of data returned or compliance with standards. See the Exceptions section of the ForwardCompatibility page. Note this hasn't been voted on yet, but that seems to be the direction we're heading. David Andreas Korneliussen wrote: David W. Van Couvering wrote: This is an example where we find our code throwing the wrong SQL State, but are we allowed to fix it? Lance says yes. Others providing support for customers say (I think) no. This ties into the discussion about the stability classification for SQL States. If we mark it as Stable, then we can't change this. If we mark it as Unstable, then we can. Comments, thoughts? Is there a document for Derby with error conditions and expected SQL state ? If there is no such document, one cannot claim that the classification for SQL state is Stable. In general, I do not think any interface can be marked as stable, unless documented. Even if we do have a document of expected error conditions and expected SQL state, we should be allowed to make bugfixes if the implementation is incorrect w.r.t the document / specification. Andreas
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
I think this is a good approach. Having the project open source solves some of these nasty bug-compatibility issues that can occur with closed-source projects with Big Customers. I'll try to add something to this effect in the Wiki page, although it may already be covered in the Exceptions section. David Oystein Grovlen - Sun Norway wrote: Daniel John Debrunner wrote: Remember this is open-source, there are no customers or important customers, only users and developers. If a user doesn't like the solution they have at least two options: - get involved in the Derby developer community - patch the source I prefer the first. Good point, Dan. Users of Derby has several options when a new release break their application: - Fix their application - Use the old release (i.e., not upgrade) - Pay someone (e.g. Sun or IBM) to fix their problem. - Get involved in the Derby community and suggest a fix to their problem. - Patch the source by reverting the fix that causes problem for them. I am pretty sure that there will case where it is NOT worth the extra effort by the community to ensure that a specific user is able to upgrade. I also think it is a violation of the Derby charter to NOT fix bugs or correct sql-states for compatibility reasons. The Derby charter states that Derby is standard compliant. If there are cases where it does not comply to the standard, we have the obligation to fix that.
Re: Monitoring/improving code coverage (was Re: code coverage results for trunk - svn revision no 390306)
I think the model we are following with functionality regressions works well. We are not necessarily preventing future checkins unless things are perceived to be Out of Hand by one or more committers. I think the same could be done for code coverage regressions. If a new chunk of code is checked in and the numbers drop way way down for a given module, I think that is cause for concern and a committer could reasonably insist that the feature is not sufficiently tested and back out the change, or at least block any future checkins in that area until enough tests are provided. So I propose having a flag raised when numbers go say 20% below current baseline for a given package, and then it is up to the committers to decide what action is necessary. David Kathey Marsden wrote: Rick Hillegas wrote: In previous lives, I've seen code-coverage metrics generated on, say, a monthly basis and used as a release barrier. I do not think they are appropriate as a barrier to checkin. I think since we seem to be going for very long release cycles instead of the release early, release often model, release barriers are not very effective for maintaining quality on the trunk. Also in open source, developers come and go so the wait until release model doesn't tend to work that well in that regard either. If Linux could release a new kernel twice a day, I tend to think that the trunk should be ready for release at any time for completed functionality and even incremental functionality could be covered. Kathey
Re: Monitoring/improving code coverage (was Re: code coverage results for trunk - svn revision no 390306)
Backing out the code was a suggestion, not a rule. What is appropriate I think depends upon the situation. My main point is it would be good to have the information made available to us in a timely and in-your-face way -- we don't have to go searching for it, and we find out right away -- so we can discuss it as a community and try to make the right decision. David Daniel John Debrunner wrote: David W. Van Couvering wrote: I think the same could be done for code coverage regressions. If a new chunk of code is checked in and the numbers drop way way down for a given module, I think that is cause for concern and a committer could reasonably insist that the feature is not sufficiently tested and back out the change, or at least block any future checkins in that area until enough tests are provided. So we could have applied this rule to JDBC 4.0 checkins. JDBC 4.0 code was checked in, the code coverage numbers decreased and could not increase until the tests could run under JDBC 4.0. In this case requiring the JDBC 4.0 changes be backed out until all the tests ran under JBDC 4.0 seems too drastic. Goes against the model of incremental development. Dan.
Re: Monitoring/improving code coverage (was Re: code coverage results for trunk - svn revision no 390306)
I think it would be great to have more awareness about code coverage, esepcially if it gets worse. Getting people to work on it is a different question, and I agree it may be difficult. I know I would be alarmed if someone checks in a complicated feature and the code coverage for those packages is say 10%, and at a minimum a discussion should ensue. But as it stands we don't even know when that happens. I liked having a goal for each release of improving the code coverage by some modest amount -- incremental improvement. Another area where I think there would be value in increasing awareness is if we have a complexity analysis tool and some package jumps in complexity by 50% after a checkin... But that's another itch for another email thread. David Daniel John Debrunner wrote: David W. Van Couvering wrote: I like the idea of having it as a release barrier, and I also like the idea of getting an email saying Code Coverage Regression and printing out the package(s) that have regressed below a low-water mark. I'm not sure a release barrier will work. If the coverage is low in a certain area and no-one has the itch to work on it then is there no release? Think about how the coverage gets low in the first place. Someone contributes an improvement with some amount of testing. I think it's reasonable to reject such a contribution if there are no-tests. Without tests there is no easy way for a committer to determine if the feature even works. Now if tests are contributed that shows the feature basically works, but have low code coverage, is there really a justification to reject the contribution? The feature basically works according to the original contributor's itch, it's someone else's itch that more tests exist. One can always request more tests from the contributor, but I'm not sure you can force it. What I am at a loss for is what the low-water mark should be. I think whatever we choose, we are going to have some immediate regressions. Then the question becomes, how much work are we willing to put into this to get it fixed. One approach that comes to mind is to set a reachable goal for each release as a step along the way to our ultimate goal. For right now, a regression could be if any package goes 10% below what our current baseline is. Then we try to raise the water each release and re-set our baseline. Not sure how we can get people to scratch the code coverage itch. It seems we can't get a lot of folks interested in fixing the 150+ bugs out there, never mind writing more tests that might uncover more bugs. I would love it if we could find a way. Bottom line is that if people don't care about code coverage they are not going to work on improving it. Dan.
truncate implemented only on network client?
I noticed that Clob.truncate() is implemented in the network driver but not in the embedded driver. I just wanted to check and see if we shouldn't be implementing truncate on the network client? Thanks, David
Re: truncate implemented only on network client?
OK, sounds good, I'll update DERBY-572 and add this as a subtask. David Satheesh Bandaram wrote: Or could that be added to Embedded under DERBY-572? Client does have a few more APIs than embedded and DERBY-572 could be modified to track extra methods that Client has wrt Clob and Blob (of JDBC3)? Satheesh On 4/3/06, *David W. Van Couvering* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I noticed that Clob.truncate() is implemented in the network driver but not in the embedded driver. I just wanted to check and see if we shouldn't be implementing truncate on the network client? Thanks, David
Another good article for Apache Derby
This talks about Java DB, Sun's distribution of Apache Derby, but I thought the tutorial/example for how to build a desktop app using NetBeans and Java DB still would be useful to Derby users. Jean, if you agree, perhaps we can put this on the web site? http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javadb/
Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)
This is an example where we find our code throwing the wrong SQL State, but are we allowed to fix it? Lance says yes. Others providing support for customers say (I think) no. This ties into the discussion about the stability classification for SQL States. If we mark it as Stable, then we can't change this. If we mark it as Unstable, then we can. Comments, thoughts? David Andreas Korneliussen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1172?page=all ] Andreas Korneliussen updated DERBY-1172: Attachment: DERBY-1172.diff DERBY-1172.stat The attached patch addresses the bug by catching and rethrowing. It also extends jdbcapi/HoldabilityTest.junit with two testcases which verfies that the correct exceptions is given. incorrect error message in updateRow() after a commit on a held scroll insensitive resultset Key: DERBY-1172 URL: http://issues.apache.org/jira/browse/DERBY-1172 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Minor Attachments: DERBY-1172.diff, DERBY-1172.stat If an application does updateRow() right after a commit on a held cursor, (without repositioning the cursor), an incorrect error message is given if the ResultSet is of type TYPE_SCROLL_INSENSITIVE. SQL 2003, Part 2: Foundation (SQL/Foundation) p 827, paragraph numbered 6): 6)If CR is a holdable cursor and a fetch statementhas not been issued against CR within the current SQL- transaction,then an exception condition is raised: invalid cursor state . and that exception has state 24000 Currently, if the ResultSet is of type TYPE_SCROLL_INSENSITIVE, it fails with SQL Exception: The scan is not positioned. state: XSCH7 : code=2 If the ResultSet is of type TYPE_FORWARD_ONLY, it gives the correct error message: SQL Exception: Invalid cursor state - no current row. state: 24000 : code=2 The first exception is given from the store layer. The SQL layer seems to catch the store exception and rethrow a new exception with correct SQL state and error message. However this is not done in TableScanResultset.getRowLocation(), which is used by scrollinsensitve cursors. A fix could be to add this logic into TableScanResultset.getRowLocation(). Or alternatively, make the store layer throw the expected exception, and remove logic to rethrow the exception.
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
I think we should clarify the page, then. My intent was not that a major release *will* be incompatible. My intent was that a major release *might* be incompatible, whereas minor releases can *not* be incompatible. David Daniel John Debrunner wrote: Kathey Marsden wrote: Rick Hillegas wrote: I think you may have already addressed the following issues in email, but I don't see the results rolled onto the wiki page. Please pardon my nitpicking. This kind of discussion turns me into a tiresome, pedantic Mr. Hyde: 1) The cardinal rule. I recommend wordsmithing the cardinal rule: The goal is to allow any application written against the public interfaces an older version of Derby can run, without any changes, against a newer version of Derby. To me the following formulation reads better This is our goal: An application which ran against Derby yesterday will run against a higher version of Derby tomorrow. I prefer the original wording with only a small grammatical change to instead of can. The goal is to allow any application written against the public interfaces an older version of Derby to run, without any changes, against a newer version of Derby. It is good to think past tomorrow. +1 The push towards allowing a major release to change things worries me. It may be that we need to do this from time to time, but it should not be the primary goal. Dan.
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
I agree this sounds like a terrible model. But we have to accept reality, we *are* going to have bugs. And if we can't fix those bugs in a backward-compatible way, then it is more than likely that some Big Huge Customer will refuse to upgrade. I saw that at Sybase as well. Perhaps the cost of supporting older codelines is ultimately a better choice for our product than the spaghetti of micro-compatbility if-statements and weird behavior plugins in the code. I don't have an easy answer. I agree we should strive for correctness, and perhaps we'll just have to cross that bridge when we come to it. I think Rick's caveats are valuable, but I don't want them to be a loophole that we then use to feel we have more free rein to break compatibility. But, saying that, knowing this lot I suspect we don't have to worry about this, you can't sneeze around here without someone worrying whether than sneeze was compatible with your last sneeze :) David Daniel John Debrunner wrote: Rick Hillegas wrote: Thanks, David. I think this discussion is raising some interesting issues. David W. Van Couvering wrote: 2) Bug fixing policy. I am glad that we are bothering to make these rules explicit. In a previous life at Sybase, we solved this problem by adding special tracepoints for big, important customers who relied on old, incorrect behavior. As I recall, we didn't know up front who would object to a correction. The tracepoints went into patch releases based on customer dissatisfaction with the last minor release. Do you think the Sybase model will work for us? Or do we need to add tracepoints to the minor release as we fix the incorrect behavior? Maybe it is not good enough to add a master tracepoint with the semantics Simulate all incorrect implementations of the standards fixed in this release, X.y. Customers may want something more granular, say, a tracepoint per obnoxious correction. Over time, these tracepoints will pile up and the code will become a more exciting pinball machine. What are your thoughts? I think it's a terrible model. This moves the project into a state where the number of possible execution time modes will increase rapidly, causing nightmares for those who have to support it or answer questions on the user list. For any change we as a community should be confident it is the correct change. [disclaimer - I was at Sybase during those times ] Dan.
Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)
Daniel John Debrunner wrote: David W. Van Couvering wrote: This is an example where we find our code throwing the wrong SQL State, but are we allowed to fix it? Lance says yes. Others providing support for customers say (I think) no. Well in this case the functionality has never been in an official release so I'm sure it can change. This ties into the discussion about the stability classification for SQL States. If we mark it as Stable, then we can't change this. If we mark it as Unstable, then we can. I'm beginning to think that the classifications are too broad. I think there are some exception SQLStates that should should not change and some that could. In my mind it depends on if a application could be using the old state in a reasonable way. Very subjective of course, not sure if we could re-write into a more formal form. I don't think we can. One suggestion I received offline was to mark the standard SQL States as Standard and the Derby-specific SQL States as Unstable. And then I think I can add a note to the SQLState column that changes may be permitted in some circumstances, and will be decided on a case-by-case basis by the community. Another example if JDBC deprecates some method then how is that represented in the table? I don't think it is. I'm not sure if this table is intended for that level of detail. Do you think it's needed? Dan.
Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)
Kathey Marsden wrote: David W. Van Couvering wrote: This is an example where we find our code throwing the wrong SQL State, but are we allowed to fix it? Lance says yes. Others providing support for customers say (I think) no. This ties into the discussion about the stability classification for SQL States. If we mark it as Stable, then we can't change this. If we mark it as Unstable, then we can. Comments, thoughts? I think it is ok and good to change an SQLState or any behaviour to fix a bug if our current behaviour is non-standard. OK, I can add that as a note to the row for SQL States. The question becomes what level of notification do we need to users and what strategy will we give them to mitigate the impact of the change? In this case, I think this is new functionality, so all very good it is caught now and dealt with. If it were existing functionality, I think that user notification would be very important. I think we need some way of marking changes that might affect existing users. I made this proposal a while back for Jira that I think would help: http://www.nabble.com/New-Jira-Checkbox-proposal-t1200029.html#a3166517 Feedback from Andrew indicated that components are preferred to checkboxes but being able to query Jira for changes that might affect users I think is important. What do people think of adding components for Release Note Needed, Existing Application Impact and Regression ? I think notification is great. I don't understand why what you are suggesting should be components they really seem to me to make sense as checkboxes -- how are these components of the system? Andrew, can you explain? David Kathey
Help with CTRL-M in test output on Windows
When I look at the diffs I have on some test output based on message text changes, I get only the lines that have changed. But in svn diff it shows the old contents completely removed and new contents put in its place, all with ^M characters at the end of each line. Any advice on how to address this? I would like reviewers to see the actual changes made versus a global replace. Thanks, David
Re: Another good article for Apache Derby
Hm, I didn't add that :) Jean T. Anderson wrote: David W. Van Couvering wrote: This talks about Java DB, Sun's distribution of Apache Derby, but I thought the tutorial/example for how to build a desktop app using NetBeans and Java DB still would be useful to Derby users. Jean, if you agree, perhaps we can put this on the web site? http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javadb/ I noticed your Wiki entry for it at http://wiki.apache.org/db-derby/DerbyInstruction#Examples -- thanks for adding that. Right now http://db.apache.org/derby/quick_start.html#Next+Steps+For+Users has this list, which sometimes links to the Wiki: * Examples * Demos * How to use Derby with other products o Database Tools + DdlUtils o IDEs + Eclipse + JBuilder + NetBeans o Data and Object/Relational Mappers + iBATIS + JPOX JDO + Torque o Web Applications + Geronimo + Tomcat 5.0 + Tomcat 5.5 + WebSphere How about providing specific links for Examples and Demos? * Examples o Using Java DB in Desktop Applications * Demos o Database-in-a-browser What else should be listed? One minor scheduling note: I'll be gone all next week. These edits to the web page are actually pretty simple, once people decide what should be listed. Would you or another committer be willing to do the edits and publish the site? I'd be more than happy to work with you (or whomever) on the forrest logistics. -jean
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
I'll let you go ponder, but I guess I don't fully understand. It is a Bad Thing at any time to break client/server compatibility. Hopefully we never have to do it. I guess my only point, and I think the point of this Wiki, is that *when* we have to do it, we have to do it at a major release boundary, and we will document clearly that there is an incompatibility. If we can make a change such that it only breaks compatibility with major release - 2 (e.g. the change in 12.0 works with 11.x clients but not with 10.x clients), that's great. We can even agree to make this a policy. But to me that doesn't meant we can make the change at a minor release boundary. David Kathey Marsden wrote: David W. Van Couvering wrote: I also wanted to respond to the suggestion that compatibility be guaranteed for a given time period, versus tying it to release levels. If we don't *require* that major releases be incompatible, but simply say this is the only time you *can* do it, then I don't see what the issue is. We can do as many major releases as we want in five years. If we want to also provide a guarantee that any feature will not be broken for five years, that's OK, but I think it would be odd to break compatibility in a minor release just because it's been five years... Or am I not fully understanding your proposal, Kathey? It is not a proposal, kind of more of a typical user requirement. I need to think some more on how to that might be implemented from a product perspective. Perhaps the guarantee of client/server compatibility with the previous and next major release would be a more realistic approach. Certainly the kind of jump suggested where there is no compatibility between v10 and v11 clients and servers would be a very hard move for users. Upgrade is another area I need to understand better across major version boundaries. Anyway, all just random thoughts at this point. As I said I need to think more. I will study your proposal and all this just as soon as I can and get back. Kathey
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
I don't know the specific bug and the impact. My intuition says document the change. But if it were a significant enough change, I might consider providing support for the old, broken behavior. I hope that this is a discussion that can be had around this bug by the contributor and his/her reviewers. David Rick Hillegas wrote: We already have to cross this bridge for the next release of Derby. DERBY-280 is a correctness bug, which while not fixed, was patched. This changes the behavior of a family of queries which were returning wrong results. What should we do: 1) Add and document a tracepoint allowing customers to get the previous incorrect behavior? Please say no. I think we all believe this is a crummy solution. 2) Document the changed behavior in the Release Notes. If an important customer complains, then we can evaluate how to satisfy that customer in a follow-on release. 3) Something else? -Rick David W. Van Couvering wrote: I agree this sounds like a terrible model. But we have to accept reality, we *are* going to have bugs. And if we can't fix those bugs in a backward-compatible way, then it is more than likely that some Big Huge Customer will refuse to upgrade. I saw that at Sybase as well. Perhaps the cost of supporting older codelines is ultimately a better choice for our product than the spaghetti of micro-compatbility if-statements and weird behavior plugins in the code. I don't have an easy answer. I agree we should strive for correctness, and perhaps we'll just have to cross that bridge when we come to it. I think Rick's caveats are valuable, but I don't want them to be a loophole that we then use to feel we have more free rein to break compatibility. But, saying that, knowing this lot I suspect we don't have to worry about this, you can't sneeze around here without someone worrying whether than sneeze was compatible with your last sneeze :) David Daniel John Debrunner wrote: Rick Hillegas wrote: Thanks, David. I think this discussion is raising some interesting issues. David W. Van Couvering wrote: 2) Bug fixing policy. I am glad that we are bothering to make these rules explicit. In a previous life at Sybase, we solved this problem by adding special tracepoints for big, important customers who relied on old, incorrect behavior. As I recall, we didn't know up front who would object to a correction. The tracepoints went into patch releases based on customer dissatisfaction with the last minor release. Do you think the Sybase model will work for us? Or do we need to add tracepoints to the minor release as we fix the incorrect behavior? Maybe it is not good enough to add a master tracepoint with the semantics Simulate all incorrect implementations of the standards fixed in this release, X.y. Customers may want something more granular, say, a tracepoint per obnoxious correction. Over time, these tracepoints will pile up and the code will become a more exciting pinball machine. What are your thoughts? I think it's a terrible model. This moves the project into a state where the number of possible execution time modes will increase rapidly, causing nightmares for those who have to support it or answer questions on the user list. For any change we as a community should be confident it is the correct change. [disclaimer - I was at Sybase during those times ] Dan.
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
I've updated the Wiki page to reflect some of this discussion and my sense of where things are ending up. You can use the diff mechanism of the Wiki to see what's changed. David Kathey Marsden wrote: Rick Hillegas wrote: I think you may have already addressed the following issues in email, but I don't see the results rolled onto the wiki page. Please pardon my nitpicking. This kind of discussion turns me into a tiresome, pedantic Mr. Hyde: 1) The cardinal rule. I recommend wordsmithing the cardinal rule: The goal is to allow any application written against the public interfaces an older version of Derby can run, without any changes, against a newer version of Derby. To me the following formulation reads better This is our goal: An application which ran against Derby yesterday will run against a higher version of Derby tomorrow. I prefer the original wording with only a small grammatical change to instead of can. The goal is to allow any application written against the public interfaces an older version of Derby to run, without any changes, against a newer version of Derby. It is good to think past tomorrow. But is that really the cardinal rule? Maybe we really mean this: This is our goal: An application which runs against a Derby release today will also run tomorrow against the next minor release. I do not like this wording .It might seem to imply that you cannot skip minor releases e.g. go from 10.l to 10.3. It might also seem to imply that you cannot run a 10.1 client with a 10.3 server for example. We strive to minimize churn for applications migrating to the next major release of Derby. However these migrations may entail application changes. The way major releases are described in this mail is the way I have seen them in the past, where we break upgrade, client/server compatibility and many other things and it is like switching to a new product, but I want better for the users of Derby 10 when they switch to 11. I still need to think a lot about the whole major version boundary thing. It seems like we like solaris will be set at the same major version for a very long time. As I stated before I think for some things a time based approach seems most appropriate. You can expect your client to work with new servers for the next five years for example. We should not just leave users trying to figure out how to upgrade their server and all of their clients all in one night because we bumped from 10 to 11. If we expect upgrade=true to work from 10 to 11 we should expect client/server compatibility to be maintained as well. So either the time based approach or for major versions have compatibility with the previous and next major versions.For example with Derby 11 you can use Derby 10 or Derby 12, but not Derby 13. 2b) Our DRDA implementation may incorrectly transport datatypes not recognized by DRDA. Conforming to the DRDA spec may mean removing this transport capability and breaking applications which select the unsupported datatypes. Protocol has an impact on client JDBC, SQL and even the ability to connect and those cannot be broken. Client and server can have version dependent behaviour to mitigate the change to DRDA compliant behavior. 3) Client/server compatibility. I would expect to find these rules spelled out on the wiki page. Yes I agree these should be spelled out because obviously different readers can deduce different things.
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Hi, Jeff. I've been quiet on this comment because I didn't fully understand it. I *think* what you're saying is that an interface can not be considered Stable or Unstable unless it's actually documented. Is that right? David Jeff Levitt wrote: From a documentation perspective, I think if we are going to say on this page that items are stable AS DOCUMENTED in the user documentation, then we also need to put in some sort of requirement on this page that says any changes made to the stability of an item MUST be documented as well in order to be committed an considered stable. Its not stable if its not documented and we are telling people that it is stable as documented. Agreed? I think this is something that would be good to put in to make sure that developers understand the importance of documenting their work, whether its something new or a change to something that exists, and that its not just going to magically show up in the documentation if they put it in the code (unless its javadoc) :) --- David W. Van Couvering [EMAIL PROTECTED] wrote: Thanks for your comments, Kathey, and yes, it can definitely wait a week. It was just so quiet that I thought I'd do a ping and see if there was more to come from everyone. Responses below... Kathey Marsden wrote: I wish I had more time to look at this but I think that I would add these things. - In general any documented behaviour is a stable interface, unless specifically documented here or in the documentation as unstable. I'm not sure how to handle this. What does it mean to incompatibly change documented behavior? Usually the behavior is in relation to a given interface. So perhaps in our definition of what it means to incompatibly change an interface means you can't change the documented behavior of that interface (e.g. the contract of that interface). I think it's also fair to say that unless explicitly called out in the table as otherwise, one can assume a publicly documented interface is Stable. - Derby will at a minimum negotiate down to the lower interface revision level: - When different versions of Derby client and server are used together (in the same or different JVM's) - When different jvm versions are used on client and server. I think this is a solution that provides a guarantee of stability to the client/server interfaces. I can add this as a note, however. I think by calling out the *specific* interfaces that the client depends upon (DRDA, metadata procedures, system stored procedures, ???) and marking them as Stable or Private Stable is a Really Good Idea in our attempts to provide the guarantee of client/server compatiblity. Note, for example, some of us newbies changing the metadata procedures willy nilly because we were unaware of the impact on compatibility. Having these called out will make us all more conscious of what we can and can't do within the system. In the interface table I would add: - Defaults returned by DatabaseMetaData methods Stable - Documented defaults Stable - console output format for tools and network server Unstable - System stored procedures Stable OK, I'll add these. I think the console output format for tools and server should actually be marked Private -- it's not documented in the user documentation, and can change at any time. Dumb question: are system stored procedures in the user documentation? If not, perhaps they should be Private Stable rather than Stable? If they're not documented, what is driving the requirement that they be stable - client/server compatibility? Under notes It would be good to mention: . OK Could we wait a week for a vote?I think I need to study this some more. Thanks David for doing this. Yes, sure, and you're welcome. David Kathey
Re: Help with CTRL-M in test output on Windows
Thanks, Andrew. I have this property set by default for new files I create, but it looks like it was never set for this existing output file. I'll try the fix you suggest and see if it works. David Andrew McIntyre wrote: On 3/31/06, David W. Van Couvering [EMAIL PROTECTED] wrote: When I look at the diffs I have on some test output based on message text changes, I get only the lines that have changed. But in svn diff it shows the old contents completely removed and new contents put in its place, all with ^M characters at the end of each line. Any advice on how to address this? I would like reviewers to see the actual changes made versus a global replace. Sounds like it's missing the svn:eol-style native property in svn. I think it might work to just set the property on a Windows machine, remove the file and then svn up to restore it with the property added. If that doesn't work, you'll need to commit the property change from a Unix machine and then update your Windows checkout to get the correct line-endings. Also, its been mentioned before, but I'll mention it again in case anyone missed it the first time. If you add the following to your local ~/subversion/.config: http://www.apache.org/dev/svn-eol-style.txt then svn will automatically add the right property when new files are added. You'll need to add *.out to this list as well. andrew
Re: Help with CTRL-M in test output on Windows
Just for posterity, it turns out *I* was the one who added these output files (jdk16 output files) and my .config did *not* have .out as a prefix for svn:eol-style=native. The template I cut-and-pasted from did not have it. Others of you out there may want to fix this. David David W. Van Couvering wrote: Thanks, Andrew. I have this property set by default for new files I create, but it looks like it was never set for this existing output file. I'll try the fix you suggest and see if it works. David Andrew McIntyre wrote: On 3/31/06, David W. Van Couvering [EMAIL PROTECTED] wrote: When I look at the diffs I have on some test output based on message text changes, I get only the lines that have changed. But in svn diff it shows the old contents completely removed and new contents put in its place, all with ^M characters at the end of each line. Any advice on how to address this? I would like reviewers to see the actual changes made versus a global replace. Sounds like it's missing the svn:eol-style native property in svn. I think it might work to just set the property on a Windows machine, remove the file and then svn up to restore it with the property added. If that doesn't work, you'll need to commit the property change from a Unix machine and then update your Windows checkout to get the correct line-endings. Also, its been mentioned before, but I'll mention it again in case anyone missed it the first time. If you add the following to your local ~/subversion/.config: http://www.apache.org/dev/svn-eol-style.txt then svn will automatically add the right property when new files are added. You'll need to add *.out to this list as well. andrew
Re: Regression checkbox (was Re: Can we change SQL State?)
Great, thanks for the quick attention to this! David Andrew McIntyre wrote: On 3/31/06, Kathey Marsden [EMAIL PROTECTED] wrote: It is the other way around. :Existing Application Impact is for things that are not regressions but rather intentional behaviour changes or fixes that might affect existing applications. An example might be a bug fix that made Derby comply with standard behaviour where it did not before.It may have existing application impact but is not a regression. Ah, I see. I don't think that was clear from the previous comments. I've added a checkbox for that as well. andrew
