Unique constraints and null
Hi folks, long time no see. :)I think I'm ready to start doing some work on Derby again (not full time, but more than zero time ;o). I was thinking of DERBY-653, which Rick H created and then closed himself during a discussion in October. I think it would be nice if Derby behaved correctly according to the SQL standard here. I see allowing nulls with unique constraints as a useful feature to have. So, considering that I've been absent for quite a while, I don't know the state of the nation and have to ask: Is this a feature the community would like to have? Does anyone object to Derby behaving this way? And is anyone working on this right now, considering working on it, or would like to? --Øyvind Bakksjø
Re: [VOTE] Rick Hillegas as a committer
+1 Øyvind (still not productive on Derby, will be getting up to speed at Google for a while...)
Re: Derby on CLDC ?
mdjerouni wrote: Hi, I develop on mobiles phones which have this JAVA configuration: MIDP 2.0 and CLDC 1.1. I’m looking for a secure database like Derby. I have read in the mailing list (November 2004) that Derby doesn’t work with CLDC. I would like to know if there is changing about this point: if Derby works today with CLDC configuration. No. CLDC lacks a number of essential features which Derby relies on (such as application-controlled class loading). I don't expect Derby to support CLDC in the near future. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Created: (DERBY-748) Should document the default schemas in a newly created database
Should document the default schemas in a newly created database --- Key: DERBY-748 URL: http://issues.apache.org/jira/browse/DERBY-748 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.2.1 Reporter: Oyvind Bakksjo A newly created database will contain the following schemas: NULLID SQLJ SYS SYSCAT SYSCS_DIAG SYSCS_UTIL SYSFUN SYSIBM SYSPROC SYSSTAT These should be documented, at least in the Reference Guide. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Apache Derby logo
Knut Anders Hatlen wrote: Since you are a committer and have a binding vote, could you clarify what you mean by this? Is it a veto or are you just expressing your opinion? No, a veto would be a -1 on something. :) I'm expressing my opinion (I agree with Brian Smith). Perhaps it was confusing since this thread has [VOTE] in the subject. I have the feeling that the vote we are doing is on whether we want some nice, professionally looking graphics versus some home-made crap. Well of course we want the nice logo. But I think the vote is a bit too much about presentation and too little about content. I'd like to see more hi-res, anti-aliased, professionally looking logos before making a decision. Keeping the Red Hat logo in mind, I'd say enough with the hats already. :) I think it's too similar, we'll look like the Red Hat database. Also, what people associate with the word Derby varies: A soccer team, a city in England, horse racing, a hat, more? But I don't object enough to veto the logo vote. ;) -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [VOTE] Apache Derby logo
Brian Smith wrote: I am not a committer. But, I am curious about why you don't have a No Logo option or a Wait for more submissions option. Firstly, I think that they name Derby is a reference to racing, which implies that the product is fast. This is a good association. However, most entries seem to be based on that fact that derby *could* also refer to a type of hat that most people have absolutely no knowledge of. I don't see how this allusion to obscure trivia is useful to the project. Besides that, there are already major, successful open-source projects using hat logos (Red Hat and Fedora). Therefore, I believe that the hat logos are all fundamentally unhelpful, regardless of their impressive artistic merits. Secondly, it seems like this logo idea was just conceived a very short time ago. The next version of Derby won't be released for some time. I don't understand why these kinds of marketing decisions cannot be deferred to a time closer to the release date. Since there is no pressing need for a logo, I think that it makes sense to wait for a really spectacular submission, even if it doesn't happen immediately. Thirdly, I think that you would get a much broader (and potentially better) set of submissions if this was announced in forums that are oriented towards graphic design. Just like I wouldn't ask the population of a woodworking convention to design lingerie, I don't think it is a good idea to ask a mailing list consisting almost exclusively of programmers to create artwork. +1 on all of the above. -- Oyvind Bakksjo
On the move
This may be of interest to some of you. I am leaving Sun Microsystems. Starting from January 2006, I will be working for Google in Trondheim, Norway. I intend to continue working on Derby, but I cannot at this point say how much. It is at least likely that I'll be preoccupied for some time during my first months at Google. I guess you'd also like to know whether Google has any interest in using and/or contributing to Derby. I cannot speak for Google at this point, all I can currently say is that they have a positive attitude towards open source software and that I will of course spread the word about Derby when I'm on the inside. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Backward compatibility of DataSource implementations
[EMAIL PROTECTED] wrote: The logic you write for creating a DataSource object based on the information in a JDNC JDNC? That's an amazing typo. JNDI! -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: context classloader versus default classloader
David W. Van Couvering wrote: The concern I have is that DatabaseClasses.loadApplicationClass() uses the thread context classloader, and if the class is not found there (or there is no context classloader), only then does it use the default classloader. Let's say I'm able to create a classloader whose search path only includes specific derby jar files (to avoid the issues of mixed versions of Derby). To avoid those issues, you need to make sure that your classloader does not delegate loading of Derby classes to its parents. You don't need to restrict the search path of your classloader to *only* derby jar files. Then let's say I try to make use of this when getting connections: URLClassLoader cl = new MyClassLoader() EmbeddedDataSource ds = (EmbeddedDataSource)(cl.loadClass(org.apache.derby.jdbc.EmbeddedDataSource).newInstance()) If you write code like this, the declaration of ds causes a load of EmbeddedDataSource through the default classloader. If this classloader cannot load Derby, you will get an exception before getting to cl.loadClass(). If it *is* able to load Derby, ds will be of a different class than the one loaded with cl.loadClass(), so the assignment will throw a ClassCastException. Connection conn = ds.getConnection(...); This effectively sets the default classloader for EmbeddedDataSource (and all its dependent classes) to be MyClassLoader. Yes, the default classloader for any class is the classloader it was loaded with. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Indentation and formatting question
Bryan Pendleton wrote: I'm having trouble getting my editor set up properly to work with the Derby source code. Can somebody send me the commonly-accepted Derby source code tab-and-spacing conventions? I'm using VIM, so ideally if somebody could point me at a .vimrc that set things up the right way... thanks, bryan P.S. Here's what I currently use; it intentionally avoids putting hard tabs into the code because I've found they don't work as well as spaces. I don't know much about VIM, but I completely agree with you on this - tabs are evil, since the width of a tab character is up to the presenting application, whereas a space is always a space. The standard indentation width in Derby is 4 monospace characters. I use 4 spaces in any new code I contribute. It doesn't always look nice mixed with the tab-indented lines if you just display a source file in a terminal window, but I don't think that's an issue. People write code in editors, and usually set up the editors to display a 4-character indentation for the tab characters. :filetype indent on :set softtabstop=4 :set shiftwidth=4 :set expandtab :set ic -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: SQLExceptions and OutOfMemoryExceptions
Lance J. Andersen wrote: I am not fond of a Singleton of a SQLException but that is just me. You would at least need to have one per thread. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: SQLExceptions and OutOfMemoryExceptions
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Lance J. Andersen wrote: I am not fond of a Singleton of a SQLException but that is just me. You would at least need to have one per thread. Why? If I have a singleton as a static and never modify it, I can safely throw it in multiple threads. It will have the fixed meangingless stack trace, but this to handle a special case. The stack trace isn't created when the Exception object is constructed, it's created when it's thrown. If you throw the same exception object from multiple threads, they will interfer with each other in unpredictable ways. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: SQLExceptions and OutOfMemoryExceptions
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: The stack trace isn't created when the Exception object is constructed, it's created when it's thrown. If you throw the same exception object from multiple threads, they will interfer with each other in unpredictable ways. That's not what I see in jdk 1.4.2, from IBM Sun and jdk 1.5. Here's a simple program that creates an exception in the method b() but throws it in a(). I always see b() in the stack trace. java.lang.Exception: from b at te.b(te.java:20) at te.a(te.java:15) at te.main(te.java:6) I've always seen exceptions have the stack trace of where they were created. That's also what the jdk 142 javadocs say for Throwable: 'A throwable contains a snapshot of the execution stack of its thread at the time it was created' OK, red herring from me. :-/ My memory must be playing games with me - I have used the create exception trick earlier to get the current stack trace, and seemed to recall that I had to actually throw-catch it to get the stack trace. But that can't be the case then. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Updated: (DERBY-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Oyvind Bakksjo updated DERBY-297: - Attachment: derbyhatlogo-lettersaligned.png Maybe someone who's more skilled with graphics than I am can take the hat idea, place all the characters on the same baseline and still make it look like a hat? My attachment doesn't look much like a hat, it just illustrates what I mean. Submit an entry for the Derby logo contest by uploading it to this issue Key: DERBY-297 URL: http://issues.apache.org/jira/browse/DERBY-297 Project: Derby Type: Task Components: Web Site Reporter: Jean T. Anderson Assignee: Jean T. Anderson Priority: Minor Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, andrew-derbyknight1.jpg, andrew-derbyknight2.jpg, derby hat.jpeg, derby4.jpg, derbyhatlogo-lettersaligned.png On May 3 Susan Cline posted a note to kick start the Derby logo contest: http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] If you have a logo to submit, please attach it to this issue. (See http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] for the suggestion on using Jira to manage logo submissions.) Discussions about the logo contest are at [EMAIL PROTECTED] To subscribe to that list, send an empty email to [EMAIL PROTECTED] More information about the Derby mail lists is at http://db.apache.org/derby/derby_mail.html . CURRENT IMAGES File : Submitter derby4.jpg : Andrew Kachalo andrew-derbyhat1.jpg : Andrew McIntyre andrew-derbyhat2.jpg : Andrew McIntyre andrew-derbyknight1.jpg : Andrew McIntyre andrew-derbyknight2.jpg : Andrew McIntyre derby_hat.jpeg: David Van Couvering -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Cannot make web site changes visible: svn: Can't open file '.svn/lock': Permission denied
The web page at http://db.apache.org/derby/papers/derby_web.html#7.+Make+web+site+changes+visible says the following: -- A Derby committer can make web site changes visible as follows: ssh -l your_apache_login people.apache.org cd /www/db.apache.org/derby svn update -- I tried: -bash-2.05b$ cd /www/db.apache.org/derby -bash-2.05b$ svn update svn: Can't open file '.svn/lock': Permission denied -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Cannot make web site changes visible: svn: Can't open file '.svn/lock': Permission denied
Jean T. Anderson wrote: What groups are you in, Oyvind? You need to be in 'db' -- are you? I thought it might be a group thing. -bash-2.05b$ groups bakksjo apcvs incubator Exactly. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Wrong placement of Derby Network Client in Derby Integration web page
In the table at http://db.apache.org/derby/integrate/misc.html#Products+by+Type Derby Network Client is listed under ODBC Drivers, not under JDBC Drivers. Surely, this must be a mistake. I'll correct it (unless someone yells :). -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
General questions about the Integration tab on the Derby web site
I don't completely understand the placement of various information related to integration of Derby in other products. What's the criteria for putting something in the Index page versus the Summary page? The few items on the Index page is the first you see. Only if you bother to follow the Summary link you'll see the rest. This might lead to the impression that there isn't much support for Derby around. Or: What makes e.g. Torque and EMMA more worthy of a front page location than e.g. Daffodil and JBoss? Should we add an Integrated Development Environment (IDE) row to the Products by Type section of the Summary page? -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Building the documentation as pdf gives OutOfMemoryError
Jeff Levitt wrote: --- [EMAIL PROTECTED] wrote: java.lang.OutOfMemoryError Has anyone else seen this? Am I doing something wrong? I'm using ant 1.6.2 and JDK 1.4. That is odd. Have you tried using the latest DITA-OT distribution. I'm using the 1.0.1 distribution. Not even sure that would help. Does it at least do the html build? Yes, it does. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Created: (DERBY-710) Building the documentation as pdf stops with OutOfMemoryError
Building the documentation as pdf stops with OutOfMemoryError - Key: DERBY-710 URL: http://issues.apache.org/jira/browse/DERBY-710 Project: Derby Type: Bug Components: Build tools Environment: Head of trunk. uname -a Linux atum22 2.4.20-31.9 #1 Tue Apr 13 18:04:23 EDT 2004 i686 i686 i386 GNU/Linux free total used free sharedbuffers cached Mem: 10308721014104 16768 0 45208 372000 -/+ buffers/cache: 596896 433976 Swap: 2096440 5877961508644 ant -version Apache Ant version 1.6.2 compiled on July 16 2004 java -version java version 1.4.2_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03) Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode) Reporter: Oyvind Bakksjo Priority: Minor The last output seen is: dita-preprocess: map2pdf: dita.map.pdf: [echo] true dita.map.fo: dita.map.merge: [xslt] Processing .../refderby.ditamap to .../temp/refderby_MERGED.xml [xslt] Loading stylesheet .../DITA-OT1.0.1/xsl/topicmerge.xsl BUILD FAILED .../build.xml:124: The following error occurred while executing this line: .../build.xml:140: The following error occurred while executing this line: .../DITA-OT1.0.1/conductor.xml:147: The following error occurred while executing this line: .../DITA-OT1.0.1/ditatargets.xml:104: The following error occurred while executing this line: .../DITA-OT1.0.1/ditatargets.xml:60: The following error occurred while executing this line: java.lang.OutOfMemoryError -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Building the documentation as pdf gives OutOfMemoryError
Andrew McIntyre wrote: On Nov 15, 2005, at 4:13 AM, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: java.lang.OutOfMemoryError Hi Oyvind, I can't currently reproduce it on my own machine, but I know I've seen this before. Could you please open a JIRA issue for this, for tracking purposes? Please make a note of the platform, Ant version, full JDK version, and any relevant machine info (like total physical RAM). Entered DERBY-710 for this. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12357683 ] Oyvind Bakksjo commented on DERBY-31: - Updated documentation which stated setQueryTimeout was not implemented. Sendingsrc/ref/rrefjdbc40794.dita Transmitting file data . Committed revision 344345. Statement.setQueryTimeout() support. Key: DERBY-31 URL: http://issues.apache.org/jira/browse/DERBY-31 Project: Derby Type: New Feature Components: JDBC Environment: ALL Reporter: Ali Demir Assignee: Oyvind Bakksjo Fix For: 10.2.0.0 Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, derbyall_report.txt Calling Statement.setQueryTimeout() throws exception saying that function is not supported. This is an important JDBC feature and is limiting our options to use Derby with our JDBC code. Implementing this JDBC function would make Derby much easier to adopt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ] Oyvind Bakksjo updated DERBY-31: Comment: was deleted Statement.setQueryTimeout() support. Key: DERBY-31 URL: http://issues.apache.org/jira/browse/DERBY-31 Project: Derby Type: New Feature Components: JDBC Environment: ALL Reporter: Ali Demir Assignee: Oyvind Bakksjo Fix For: 10.2.0.0 Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, derbyall_report.txt Calling Statement.setQueryTimeout() throws exception saying that function is not supported. This is an important JDBC feature and is limiting our options to use Derby with our JDBC code. Implementing this JDBC function would make Derby much easier to adopt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Building the documentation as pdf gives OutOfMemoryError
The last output seen is: dita-preprocess: map2pdf: dita.map.pdf: [echo] true dita.map.fo: dita.map.merge: [xslt] Processing .../refderby.ditamap to .../temp/refderby_MERGED.xml [xslt] Loading stylesheet .../DITA-OT1.0.1/xsl/topicmerge.xsl BUILD FAILED .../build.xml:124: The following error occurred while executing this line: .../build.xml:140: The following error occurred while executing this line: .../DITA-OT1.0.1/conductor.xml:147: The following error occurred while executing this line: .../DITA-OT1.0.1/ditatargets.xml:104: The following error occurred while executing this line: .../DITA-OT1.0.1/ditatargets.xml:60: The following error occurred while executing this line: java.lang.OutOfMemoryError Has anyone else seen this? Am I doing something wrong? I'm using ant 1.6.2 and JDK 1.4. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Created: (DERBY-708) Client driver truncates database names with spaces
Client driver truncates database names with spaces -- Key: DERBY-708 URL: http://issues.apache.org/jira/browse/DERBY-708 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.2 Reporter: Oyvind Bakksjo Try connecting with e.g. 'jdbc:derby://localhost/foo bar;create=true' - the database directory created will be named foo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[ http://issues.apache.org/jira/browse/DERBY-506?page=comments#action_12357597 ] Oyvind Bakksjo commented on DERBY-506: -- Sendingjava/client/org/apache/derby/client/am/PreparedStatement.java Sendingjava/client/org/apache/derby/client/am/Statement.java Sendingjava/drda/org/apache/derby/impl/drda/DRDAConnThread.java Sending java/testing/org/apache/derbyTesting/functionTests/suites/DerbyNetClient.exclude Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/SetQueryTimeoutTest.java Transmitting file data . Committed revision 344147. Implement Statement.setQueryTimeout in the Client Driver Key: DERBY-506 URL: http://issues.apache.org/jira/browse/DERBY-506 Project: Derby Type: New Feature Components: JDBC Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Attachments: DERBY-506.diff, DERBY-506.status Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver does not. The Client Driver should be enhanced and match the Embedded Driver. For this, we need to transfer the timeout value from the client to the server, preferably without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we need to extend the Derby grammar; only the Network Server needs to understand this DRDA EXCSQLSET command). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[ http://issues.apache.org/jira/browse/DERBY-506?page=all ] Oyvind Bakksjo resolved DERBY-506: -- Resolution: Fixed Had to disable some testing because of DERBY-694 Implement Statement.setQueryTimeout in the Client Driver Key: DERBY-506 URL: http://issues.apache.org/jira/browse/DERBY-506 Project: Derby Type: New Feature Components: JDBC Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Attachments: DERBY-506.diff, DERBY-506.status Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver does not. The Client Driver should be enhanced and match the Embedded Driver. For this, we need to transfer the timeout value from the client to the server, preferably without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we need to extend the Derby grammar; only the Network Server needs to understand this DRDA EXCSQLSET command). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[ http://issues.apache.org/jira/browse/DERBY-506?page=all ] Oyvind Bakksjo closed DERBY-506: Implement Statement.setQueryTimeout in the Client Driver Key: DERBY-506 URL: http://issues.apache.org/jira/browse/DERBY-506 Project: Derby Type: New Feature Components: JDBC Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Attachments: DERBY-506.diff, DERBY-506.status Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver does not. The Client Driver should be enhanced and match the Embedded Driver. For this, we need to transfer the timeout value from the client to the server, preferably without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we need to extend the Derby grammar; only the Network Server needs to understand this DRDA EXCSQLSET command). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-705) Re-enable test which was disabled in DERBY-506 commit
Re-enable test which was disabled in DERBY-506 commit - Key: DERBY-705 URL: http://issues.apache.org/jira/browse/DERBY-705 Project: Derby Type: Test Components: Test Reporter: Oyvind Bakksjo Priority: Trivial Testing of concurrent executions on same connection was disabled in DERBY-506 commit because of DERBY-694 bug. Re-enable when DERBY-694 is fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[ http://issues.apache.org/jira/browse/DERBY-506?page=all ] Oyvind Bakksjo updated DERBY-506: - Attachment: (was: DERBY-506_PRE.diff) Implement Statement.setQueryTimeout in the Client Driver Key: DERBY-506 URL: http://issues.apache.org/jira/browse/DERBY-506 Project: Derby Type: New Feature Components: JDBC Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver does not. The Client Driver should be enhanced and match the Embedded Driver. For this, we need to transfer the timeout value from the client to the server, preferably without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we need to extend the Derby grammar; only the Network Server needs to understand this DRDA EXCSQLSET command). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[ http://issues.apache.org/jira/browse/DERBY-506?page=all ] Oyvind Bakksjo updated DERBY-506: - Attachment: DERBY-506.status Implement Statement.setQueryTimeout in the Client Driver Key: DERBY-506 URL: http://issues.apache.org/jira/browse/DERBY-506 Project: Derby Type: New Feature Components: JDBC Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Attachments: DERBY-506.diff, DERBY-506.status Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver does not. The Client Driver should be enhanced and match the Embedded Driver. For this, we need to transfer the timeout value from the client to the server, preferably without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we need to extend the Derby grammar; only the Network Server needs to understand this DRDA EXCSQLSET command). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[ http://issues.apache.org/jira/browse/DERBY-506?page=all ] Oyvind Bakksjo updated DERBY-506: - Attachment: DERBY-506.diff Diff from revision 332067. Implement Statement.setQueryTimeout in the Client Driver Key: DERBY-506 URL: http://issues.apache.org/jira/browse/DERBY-506 Project: Derby Type: New Feature Components: JDBC Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Attachments: DERBY-506.diff, DERBY-506.status Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver does not. The Client Driver should be enhanced and match the Embedded Driver. For this, we need to transfer the timeout value from the client to the server, preferably without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we need to extend the Derby grammar; only the Network Server needs to understand this DRDA EXCSQLSET command). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New features for next release .... (Was: Grant and Revoke ... DERBY-464...)
Satheesh Bandaram wrote: I noticed several other new feature work being proposed and actively being worked, possibly in time for next 10.2 release. Here is the updated list I have so far. Let me know if I missed anything. 1. JDBC 4.0 Stub implementation 2. Unary Plus/Minus. 3. Code sharing proposal. 4. Optimizer hints 5. Timeout support in Derby client. 6. Grant/Revoke in Derby 7. I18 support and SQLStates for Derby client messages. 8. Updatable, scrollable result sets 9. New datatype(s) (Boolean) 10. Making FOR UPDATE optional 11. Online backup 12. XML enhancements for XPATH/XQuery support 13. setQueryTimeout for Derby client 14. ALTER Table DROP COLUMN Satheesh Are 5 and 13 duplicates, or is 5 a different kind of timeout? -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Created: (DERBY-694) Statement exceptions cause all the connection's result sets to be closed with the client driver
Statement exceptions cause all the connection's result sets to be closed with the client driver --- Key: DERBY-694 URL: http://issues.apache.org/jira/browse/DERBY-694 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.1 Reporter: Oyvind Bakksjo Priority: Minor Scenario: Autocommit off. Have two prepared statements, calling executeQuery() on both, giving me two result sets. Can fetch data from both with next(). If one statement gets an exception (say, caused by a division by zero), not only this statement's result set is closed, but also the other open resultset. This happens with the client driver, whereas in embedded mode, the other result set is unaffected by the exception in the first result set (as it should be). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-694) Statement exceptions cause all the connection's result sets to be closed with the client driver
[ http://issues.apache.org/jira/browse/DERBY-694?page=all ] Oyvind Bakksjo updated DERBY-694: - Attachment: StatementRollbackTest.java Attached program which demonstrates the bug. Statement exceptions cause all the connection's result sets to be closed with the client driver --- Key: DERBY-694 URL: http://issues.apache.org/jira/browse/DERBY-694 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.1 Reporter: Oyvind Bakksjo Priority: Minor Attachments: StatementRollbackTest.java Scenario: Autocommit off. Have two prepared statements, calling executeQuery() on both, giving me two result sets. Can fetch data from both with next(). If one statement gets an exception (say, caused by a division by zero), not only this statement's result set is closed, but also the other open resultset. This happens with the client driver, whereas in embedded mode, the other result set is unaffected by the exception in the first result set (as it should be). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-663) Test of derby fails because difference in encoding of eol make sizes of test data files different between platforms.
[ http://issues.apache.org/jira/browse/DERBY-663?page=all ] Oyvind Bakksjo resolved DERBY-663: -- Fix Version: 10.2.0.0 Resolution: Fixed Test of derby fails because difference in encoding of eol make sizes of test data files different between platforms. Key: DERBY-663 URL: http://issues.apache.org/jira/browse/DERBY-663 Project: Derby Type: Bug Versions: 10.2.0.0 Environment: [EMAIL PROTECTED]:~/ProgramDev/derby/trunk$ cat /proc/version Linux version 2.4.27-2-386 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Mon May 16 16:47:51 JST 2005 Reporter: Tomohito Nakayama Assignee: Oyvind Bakksjo Fix For: 10.2.0.0 I found concrete failure in jdbc/resultsetStream.java . * Diff file jdbcapi/jdbcapi/resultsetStream.diff *** Start: resultsetStream jdk1.5.0_03 jdbcapi:jdbcapi 2005-10-29 20:16:58 *** 10 del len=56 11 del number of reads=56 11a10,11 len=55 number of reads=55 Test Failed. *** End: resultsetStream jdk1.5.0_03 jdbcapi:jdbcapi 2005-10-29 20:17:00 *** Surveying code and history of source repository, this test program seems to fail because test program suppose size of data file named short.txt as 56 bytes assuming data file encodes eol as CR LF . There seems to be some more substantially same failures . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Characters replacement function
[EMAIL PROTECTED] wrote:
Hello,
First I apologize for my poor english...
No need, it's fine. :)
I'm looking for a simple way to implement a character replacement function.
I'm trying to do an application migration from WSAD/DB2 to Tomcat/Derby but
there are a lot of SQL queries which use the REPLACE(SOURCE STRING, OLD
CHARACTER, NEW CHARACTER) function. It seems that this function is not
built into Derby.
Do you have an idea?
Derby supports user-defined functions, which can be any (static)
function you can access from java. I don't even think you need to write
the function yourself, you can simply use java.lang.String's replace()
method. Try something like this (I haven't tested it myself):
Create the static java function:
public static String replace(String str, char old, char new)
{
return str.replace(old, new);
}
Create a SQL function using this statement:
CREATE FUNCTION REPLACE(STR VARCHAR, OLD CHAR(1), NEW CHAR(1)) RETURNS
VARCHAR PARAMETER STYLE JAVA NO SQL LANGUAGE JAVA EXTERNAL NAME
'your.class.Name.replace'
I'm unsure about the data types in the definition of REPLACE, perhaps
what I've written doesn't work. It a) has to be correct syntax and b)
must map to the correct java types in your function. I haven't done this
with String/char parameters before (only int/INTEGER), so that's why I'm
unsure of this. Perhaps someone else can shine some light on this.
Otherwise, consult the manuals - it's not easy to find, but it's there
(somewhere).
--
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway
http://weblogs.java.net/blog/bakksjo/
Re: Characters replacement function
Fernanda Pizzorno wrote:
Hello,
Have you tried to create a user defined function for replace? You can do
that using the CREATE FUNCTION statement
(http://db.apache.org/derby/docs/10.1/ref/rrefcreatefunctionstatement.html).
I have tried creating a very simple java method that does the replace
and it seems to work fine.
Here is what I tried:
1. Java method
public static String replace (String orgStr, String oldStr, String
newStr) {
return orgStr.replace(oldStr, newStr);
}
2. User defined function
CREATE FUNCTION REPLACE(orgStr VARCHAR(50), oldStr VARCHAR(50),
newStr VARCHAR(50)) RETURNS VARCHAR(50)
PARAMETER STYLE JAVA NO SQL LANGUAGE JAVA
EXTERNAL NAME 'StringReplaceTest.replace';
3. Test
ij values replace('fernanda', 'a', 'e');
1
fernende
What happens if you execute values replace('banana', 'an', 'ul')? How
does VARCHAR(50) map to a java char?
--
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway
http://weblogs.java.net/blog/bakksjo/
[jira] Commented: (DERBY-663) Test of derby fails because difference in encoding of eol make sizes of test data files different between platforms.
[ http://issues.apache.org/jira/browse/DERBY-663?page=comments#action_12356634 ] Oyvind Bakksjo commented on DERBY-663: -- Sending java/testing/org/apache/derbyTesting/functionTests/testData/ImportExport/position_info.del Transmitting file data . Committed revision 330289. Some tests expect this file to have CRLF newlines. Test of derby fails because difference in encoding of eol make sizes of test data files different between platforms. Key: DERBY-663 URL: http://issues.apache.org/jira/browse/DERBY-663 Project: Derby Type: Bug Versions: 10.2.0.0 Environment: [EMAIL PROTECTED]:~/ProgramDev/derby/trunk$ cat /proc/version Linux version 2.4.27-2-386 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Mon May 16 16:47:51 JST 2005 Reporter: Tomohito Nakayama Assignee: Oyvind Bakksjo I found concrete failure in jdbc/resultsetStream.java . * Diff file jdbcapi/jdbcapi/resultsetStream.diff *** Start: resultsetStream jdk1.5.0_03 jdbcapi:jdbcapi 2005-10-29 20:16:58 *** 10 del len=56 11 del number of reads=56 11a10,11 len=55 number of reads=55 Test Failed. *** End: resultsetStream jdk1.5.0_03 jdbcapi:jdbcapi 2005-10-29 20:17:00 *** Surveying code and history of source repository, this test program seems to fail because test program suppose size of data file named short.txt as 56 bytes assuming data file encodes eol as CR LF . There seems to be some more substantially same failures . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: codeline health
David W. Van Couvering wrote: To be fair (a) it works fine on Windows, which is probably the platform the committer(s) tested with and (b) it has only been one working day. Actually, I ran derbyall with two unrelated failures on linux before committing. But I realize now what's happened. We're a victim of a little strange subversion behaviour. Setting the svn:eol-style property on a file before committing it does *not* change the contents of the file in your local sandbox. So derbyall will run as before, regardless of the platform. 'svn diff' reports only a bunch of property changes on the files, but no actual content diffs. Now, when the patch is *committed*, suddenly all the files' content changes. Thus, these failures were not caught before committing, but after. I'm sorry about the consequences for you all, and I'll go ahead and try to fix the issues. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: eol and merge problems from trunk to branch
Mike Matrigali wrote: In my svn commit of 329494, when I went to merge it to the branch I got a conflict on every line of the change - all eol issues. My questions are: 1) did I just get unlucky with my timing vs. the recent eol mass change? 2) Did I do something wrong with my original checkin, or something with the merge command (kathy tried the merge and got the same conficts)? 3) Is this going to happen with all future trunk to branch merges? If you merge a patch from the trunk after rev 329187 to a branch made before rev 329187 and to which the 329187 commit has not been merged, you will get this problem. Also, if you merge a patch from the trunk _before_ rev 329187 to a branch which was made after 329187 (or the 329187 checkin _has_ been merged to that branch), you will also get into this situation (but that should be a much less frequent problem). This is because Subversion does not understand that the diff is because of a property change, and that's a pity. Subversion is, with respect to the eol-style property change, as stupid as CVS is to moving/renaming files. :o( -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Commented: (DERBY-663) Test of derby fails because difference in encoding of eol make sizes of test data files different between platforms.
[ http://issues.apache.org/jira/browse/DERBY-663?page=comments#action_12356502 ] Oyvind Bakksjo commented on DERBY-663: -- Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/aclob.txt Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/empty.txt Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/littleclob.txt Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/searchclob.txt Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/short.txt Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/derby.banner Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/empty.data Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/short.data Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/shortbanner Transmitting file data ... Committed revision 330042. This hopefully fixes the problem (will not know for sure until tests have finished running). Test of derby fails because difference in encoding of eol make sizes of test data files different between platforms. Key: DERBY-663 URL: http://issues.apache.org/jira/browse/DERBY-663 Project: Derby Type: Bug Versions: 10.2.0.0 Environment: [EMAIL PROTECTED]:~/ProgramDev/derby/trunk$ cat /proc/version Linux version 2.4.27-2-386 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Mon May 16 16:47:51 JST 2005 Reporter: Tomohito Nakayama Assignee: Oyvind Bakksjo I found concrete failure in jdbc/resultsetStream.java . * Diff file jdbcapi/jdbcapi/resultsetStream.diff *** Start: resultsetStream jdk1.5.0_03 jdbcapi:jdbcapi 2005-10-29 20:16:58 *** 10 del len=56 11 del number of reads=56 11a10,11 len=55 number of reads=55 Test Failed. *** End: resultsetStream jdk1.5.0_03 jdbcapi:jdbcapi 2005-10-29 20:17:00 *** Surveying code and history of source repository, this test program seems to fail because test program suppose size of data file named short.txt as 56 bytes assuming data file encodes eol as CR LF . There seems to be some more substantially same failures . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: eol and merge problems from trunk to branch
Mike Matrigali wrote: In my svn commit of 329494, when I went to merge it to the branch I got a conflict on every line of the change - all eol issues. My questions are: 1) did I just get unlucky with my timing vs. the recent eol mass change? 2) Did I do something wrong with my original checkin, or something with the merge command (kathy tried the merge and got the same conficts)? 3) Is this going to happen with all future trunk to branch merges? By the way, GNU patch is able to recognize newline changes. What patch program do people use on Windows? Is there any way to control how svn does diffing and patching when invoking the merge subcommand? -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: HEADS UP: DERBY-330 commit is huge
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: So I did the scripts in one commit, and now I've done the rest. Sorry if all you get to do today is run 'svn update'... Like I said, probably never a good time to do this, except it should have been done at the very beginning of this repository. Transmitting file data . Committed revision 329187. Does that mean that I can close and resolve DERBY-330? Yes. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [jira] Commented: (DERBY-231) FOR UPDATE required for updatable result set to work
Dag H. Wanvik wrote: Hi, Andreas2) Applications use the FOR UPDATE clause to control locking for Andreas future updates with read only ResultSets. Andreas Andreas Andreas Note currently it throws an exception if the statement is not updatable Andreas i.e contains a join or order by. I guess what you mean here is that the FOR UPDATE is not in general available as a means for locking for future updates. To Dan's point, my tests indicate that the current Derby implementation for forward-only updatable result sets only sets a row update lock while on the current row. In contrast, Oracle's FOR UPDATE places locks on the entire result set for the duration of the transaction (see below). The usefulness as a way to control locking would be more useful if the Derby locking was closer to what Oracle does, at the expense of concurrency. Dag Just a little pick at the wording... What's useful behaviour depends on the application and its needs. If you don't need update locks on the entire result set, the usefulness of such a behaviour is negative, since it only reduces concurrency and, as such, overall performance. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
HEADS UP: DERBY-330 commit is huge (was: Re: [VOTE] 10.1.2.0 release)
[EMAIL PROTECTED] wrote: Kathey Marsden wrote: Are you volunteering? Sure, I can do that. Just hope nobody will complain - as I understand it, doing the whole DERBY-330 thing potentially creates a huge diff, which may cause conflicts when other developers update with local modifications. But I suspect there will never be a Good Time to do this. I think I'll just fix the scripts first. So I did the scripts in one commit, and now I've done the rest. Sorry if all you get to do today is run 'svn update'... Like I said, probably never a good time to do this, except it should have been done at the very beginning of this repository. Transmitting file data . Committed revision 329187. Any chocolate for contributing the largest patch? ;o) -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [VOTE] 10.1.2.0 release
Knut Anders Hatlen wrote:
-1
All the ksh scripts are have CRLF line terminators and therefore don't
work under unix.
% ksh ij.ksh
ij.ksh[13]: ^M: not found
ij.ksh[15]: ^M: not found
ij.ksh[16]: {^M: not found
ij.ksh[17]:
/tmp/derbyrc/db-derby-10.1.2.0-bin/frameworks/embedded/bin/setEmbeddedCP.ksh^M:
not found
In addition, frameworks/readme.html says:
To use the scripts for a particular framework, modify the scripts as
necessary and put that framework's bin subdirectory first in your
path.
This won't work since the scripts don't have the executable bit set.
The quick solution is running this before packaging:
find . -name *.ksh | xargs perl -pi -e 's/\r\n/\n/g'
find . -name *.ksh | xargs chmod 755
The right solution is fixing DERBY-330.
Following up on this, I think the recommended property list at
http://www.apache.org/dev/svn-eol-style.txt contains errors.
Platform-specific files should have platform-specific eol-style, so that
they will be correct for the deployment platform, whatever the build
platform is:
*.bat = svn:eol-style=native # Should be CRLF
*.sh = svn:eol-style=native # Should be LF
There should also be an entry like this:
*.ksh = svn:eol-style=LF
--
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway
http://weblogs.java.net/blog/bakksjo/
Re: [VOTE] 10.1.2.0 release
Kathey Marsden wrote: [EMAIL PROTECTED] wrote: I think the properties should be changed on the trunk and then merged to the branch. This might be a good time to fix up all the property issues in DERBY-330, in addition to these. Are you volunteering? Sure, I can do that. Just hope nobody will complain - as I understand it, doing the whole DERBY-330 thing potentially creates a huge diff, which may cause conflicts when other developers update with local modifications. But I suspect there will never be a Good Time to do this. I think I'll just fix the scripts first. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [VOTE] 10.1.2.0 release
Andrew McIntyre wrote: On Oct 27, 2005, at 7:48 AM, Kathey Marsden wrote: [EMAIL PROTECTED] wrote: Katheshould be fine. I haven't tested this though. I think the properties should be changed on the trunk and then merged to the branch. This might be a good time to fix up all the property issues in DERBY-330, in addition to these. Are you volunteering? Sendingframeworks/NetworkServer/bin/NetworkServerControl.bat Sendingframeworks/NetworkServer/bin/NetworkServerControl.ksh Sendingframeworks/NetworkServer/bin/dblook.bat Sendingframeworks/NetworkServer/bin/dblook.ksh Sendingframeworks/NetworkServer/bin/ij.bat Sendingframeworks/NetworkServer/bin/ij.ksh Sendingframeworks/NetworkServer/bin/setNetworkClientCP.bat Sendingframeworks/NetworkServer/bin/setNetworkClientCP.ksh Sendingframeworks/NetworkServer/bin/setNetworkServerCP.bat Sendingframeworks/NetworkServer/bin/setNetworkServerCP.ksh Sendingframeworks/NetworkServer/bin/startNetworkServer.bat Sendingframeworks/NetworkServer/bin/startNetworkServer.ksh Sendingframeworks/NetworkServer/bin/stopNetworkServer.bat Sendingframeworks/NetworkServer/bin/stopNetworkServer.ksh Sendingframeworks/NetworkServer/bin/sysinfo.bat Sendingframeworks/NetworkServer/bin/sysinfo.ksh Sendingframeworks/embedded/bin/dblook.bat Sendingframeworks/embedded/bin/dblook.ksh Sendingframeworks/embedded/bin/ij.bat Sendingframeworks/embedded/bin/ij.ksh Sendingframeworks/embedded/bin/setEmbeddedCP.bat Sendingframeworks/embedded/bin/setEmbeddedCP.ksh Sendingframeworks/embedded/bin/sysinfo.bat Sendingframeworks/embedded/bin/sysinfo.ksh Sending java/testing/org/apache/derbyTesting/upgradeTests/runphases.ksh Transmitting file data Committed revision 328911. No need. Dyre already submitted a script for fixing all of the svn properties. I hadn't finished reviewing it before I got distracted by other things. Looks like now's a good time to finish reviewing it. Sorry, I got to it before you. ;o) Didn't see your email before I committed. Dyre's original patch was getting out of date, plus it didn't take into account the platform-specific scripts. It so happens that Dyre's office is 7 meters from mine, so I just got him to give me his script for creating the script (seriously...), so I could apply a fresher patch. But if you're in the mood for committing, I have something for you - you could merge this patch onto the branch - it's getting late here and I would like to go home and get something to eat :o) As for the linefeeds, I think the correct solution is to fix up the line feeds for the tars and not the zips using Ant's FixCRLF task. I believe that for shell-emulation environments on Windows that the linefeeds should still be CRLF, not LF, but could somebody confirm that? I disagree, that would push the problem to everyone building on one platform and deploying on multiple, for all releases from now and forever. Any decent shell-emulation environment must IMHO take into account that shell scripts are LF terminated (at least cygwin does). Just as any emulator running .bat files on a unix would have to deal with CRLF. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [VOTE] 10.1.2.0 release
Andrew McIntyre wrote: I believe .subversion/config overrides properties in the repostiory, so if someone had svn:eol-style native for .sh and .bat in their .subversion/config, as is currently recommended by http://www.apache.org/dev/svn-eol-style.txt, then .bats and .shs would end up being LF on Linux. No, automatic property setting only applies to the svn add and svn import commands. Properties are not changed on a file when you simply check it out. From the Subversion book: Whenever you introduce a file to version control using the svn add or svn import commands, Subversion runs a very basic heuristic to determine if that file consists of human-readable or non-human-readable content. If the latter is the decision made, Subversion will automatically set the svn:mime-type property on that file to application/octet-stream (the generic “this is a collection of bytes” MIME type). Of course, if Subversion guesses incorrectly, or if you wish to set the svn:mime-type property to something more precise—perhaps image/png or application/x-shockwave-flash—you can always remove or edit that property. Subversion also provides the auto-props feature, which allows you to create mappings of filename patterns to property names and values. These mappings are made in your runtime configuration area. They again affect adds and imports, and not only can override any default MIME type decision made by Subversion during those operations, they can also set additional Subversion or custom properties, too. For example, you might create a mapping that says that any time you add JPEG files—ones that match the pattern *.jpg—Subversion should automatically set the svn:mime-type property on those files to image/jpeg. Or perhaps any files that match *.cpp should have svn:eol-style set to native, and svn:keywords set to Id. Auto-prop support is perhaps the handiest property related tool in the Subversion toolbox. See the section called “Config” for more about configuring that support. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [VOTE] 10.1.2.0 release
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Dyre's original patch was getting out of date, plus it didn't take into account the platform-specific scripts. It so happens that Dyre's office is 7 meters from mine, so I just got him to give me his script for creating the script (seriously...), so I could apply a fresher patch. You forgot to mention that the script had bug :) It tried to do svn propdel svn::executable with two colons (old C++ habits) in the property name. Should I perhaps delete this script from DERBY-330? Yeah, it had another bug as well, but I thought I should save you the embarassment. :-p I think you can delete the script from the Jira issue, now that I have the script which creates the script. :) I will commit a fix to all the files (not just the scripts) when I've checked that it does not do more than it should. We can then close the issue. These are the file types (endings) that are currently under version control: ant banner bat classpath dat data del html inc jar java jj minisql out project properties runall sql sql1 sql2 subsql tests tmpl txt view xml I'm verifying whether all of these really should have the 'svn:eol-style native' property setting. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [VOTE] 10.1.2.0 release
[EMAIL PROTECTED] wrote: I think you can delete the script from the Jira issue, now that I have the script which creates the script. :) I will commit a fix to all the files (not just the scripts) when I've checked that it does not do more than it should. We can then close the issue. These are the file types (endings) that are currently under version control: ant banner bat classpath dat data del html inc jar java jj minisql out project properties runall sql sql1 sql2 subsql tests tmpl txt view xml I'm verifying whether all of these really should have the 'svn:eol-style native' property setting. Hm. Have a look at this file: trunk/java/testing/org/apache/derbyTesting/functionTests/testData/ImportExport/mixednl.del What's the correct eol-style for this one?? :o) -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [VOTE] 10.1.2.0 release
Andrew McIntyre wrote: On Oct 27, 2005, at 10:59 AM, Knut Anders Hatlen wrote: 3. txt files, README and friends have CRLF in zips and LF in tars. Forgot about those. Good point. Me too. I think these should have eol-style native in the repository, so that you can check them out and have them in your platform's native format. When building something that is meant for distribution, one will have to make a choice. Seems like a good candidate for your ant trick. :) I agree on the tar.gz is for unix, zip is for windows line of thinking, but since this is not strictly the case, the downloads should be marked properly. But if they are going to be different (and I'm not saying they should be) we certainly have to label the files clearly on the download page, like: db-derby-10.1.2.0.zip (Windows CRLF line terminators) db-derby-10.1.2.0.tar.gz (Unix LF line terminators) I agree. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [PATCH] [jira] Updated: (DERBY-555) Unable to restart after disk is full
Øystein Grøvlen wrote: I am still waiting for (hopefully) final review/commit of this patch. The patch looked OK to me, so I committed it. Sendingjava/engine/org/apache/derby/iapi/reference/MessageId.java Sendingjava/engine/org/apache/derby/impl/store/raw/RawStore.java Sending java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java Sendingjava/engine/org/apache/derby/loc/messages_en.properties Adding java/testing/org/apache/derbyTesting/functionTests/master/TurnsReadOnly.out Adding java/testing/org/apache/derbyTesting/functionTests/tests/store/TurnsReadOnly.java Adding java/testing/org/apache/derbyTesting/functionTests/tests/store/TurnsReadOnly_app.properties Sending java/testing/org/apache/derbyTesting/functionTests/tests/store/copyfiles.ant Transmitting file data Committed revision 325896. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/ ~ CONFIDENTIALITY NOTICE: If you are not the intended recipient of this email message, then I guess I should not have sent it to you in the first place. ~
[jira] Commented: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[
http://issues.apache.org/jira/browse/DERBY-506?page=comments#action_12331714 ]
Oyvind Bakksjo commented on DERBY-506:
--
Sending the EXCSQLSET when the JDBC call [to Statement.setQueryTimeout()] is
made would cause an additional round-trip between the client and the server,
which is what I was trying to avoid by piggybacking the execute flow. Are you
concerned with the extra bytes sent during the execute call? For a prepared
statement, we only need to transmit the timeout once; for the first execute (or
if the timeout is changed with a subsequent call to setQueryTimeout() on the
client side). In code like the example below, we would only need to piggyback
the execute message for the first iteration, thus avoiding both an extra
round-trip and message overhead.
PreparedStatement ps = connection.prepareStatement(SQL);
ps.setQueryTimeout(TIMEOUT);
while (condition) {
ps.execute();
}
Have I understood you correctly, or do you have other concerns that makes you
prefer transmitting the timeout at the JDBC call time? By the way, is that
viable for unprepared statements (the server does not yet know about the
statement for which the client sets a timeout)?
Implement Statement.setQueryTimeout in the Client Driver
Key: DERBY-506
URL: http://issues.apache.org/jira/browse/DERBY-506
Project: Derby
Type: New Feature
Components: JDBC
Versions: 10.1.1.0
Reporter: Oyvind Bakksjo
Assignee: Oyvind Bakksjo
Attachments: DERBY-506_PRE.diff
Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the
Client Driver does not. The Client Driver should be enhanced and match the
Embedded Driver.
For this, we need to transfer the timeout value from the client to the
server, preferably without a separate round-trip. I have some loose thoughts
on how to do this:
* If the client has set a timeout value for a statement, prepend the (DRDA)
EXCSQLSTT command with an EXCSQLSET command which contains the timeout value;
conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we
need to extend the Derby grammar; only the Network Server needs to understand
this DRDA EXCSQLSET command).
* In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the
SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the
coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET
statement [see note below].
* In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set;
if so, use it (by setting the timeout value on the server-side Statement
object before calling execute/executeQuery).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[
http://issues.apache.org/jira/browse/DERBY-506?page=comments#action_12331738 ]
Oyvind Bakksjo commented on DERBY-506:
--
I understand your points, but with regards to setQueryTimeout(), I honestly
think you're making too much of this. ;-) To make my point clearer, I don't
(logically) think of the setQueryTimeout call as a separate request which gets
queued, it's just setting an attribute of a statement before it is executed.
Without the execute, setting the attribute has no meaning, so it is ok to flow
the attribute together with the execute request. I don't see any issues with
keeping client and server in sync, and the only error message related to the
setQueryTimeout call we need to handle is if the user supplies a negative value.
Consider this:
PreparedStatement ps = connection.prepareStatement(SQL);
ps.setMaxFieldSize(512);
ps.setMaxRows(100);
ps.setFetchDirection(ResultSet.FETCH_FORWARD);
ps.setFetchSize(10);
ps.setQueryTimeout(10);
while (condition) {
ResultSet rs = ps.execute();
}
None of the other setX() calls result in a round trip to the server. The
difference, as I see it, is simply that the DRDA protocol does not have a field
for the timeout attribute (the protocol does not target JDBC, and SQL has no
such attribute for statements). This is what forces my slight abuse of
EXCSQLSET for transferring the attribute to the server.
I really think extra round trips are a big deal in terms of performance, so I
would prefer to avoid that. We have done some in-house performance comparisons
with other open source databases and discovered that Derby uses more round
trips per transaction than the others, and that this actually matters.
My point with unprepared statements is that you cannot send a timeout value in
an separate round trip and bind it to a statement which hasn't reached the
server yet, it has to flow with the execute operation. And yes, I know
unprepared statements use EXCSQLIMM, so I'll have to add the EXCSQLSET to this
operation as well (the patch I have attached was just meant to illustrate the
approach, it's not complete).
In my opinion, setQueryTImeout is relevant to all kinds of DML statements, not
just selects. (We already had a discussion about the semantics for timeout,
what it should apply to etc.)
Implement Statement.setQueryTimeout in the Client Driver
Key: DERBY-506
URL: http://issues.apache.org/jira/browse/DERBY-506
Project: Derby
Type: New Feature
Components: JDBC
Versions: 10.1.1.0
Reporter: Oyvind Bakksjo
Assignee: Oyvind Bakksjo
Attachments: DERBY-506_PRE.diff
Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the
Client Driver does not. The Client Driver should be enhanced and match the
Embedded Driver.
For this, we need to transfer the timeout value from the client to the
server, preferably without a separate round-trip. I have some loose thoughts
on how to do this:
* If the client has set a timeout value for a statement, prepend the (DRDA)
EXCSQLSTT command with an EXCSQLSET command which contains the timeout value;
conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we
need to extend the Derby grammar; only the Network Server needs to understand
this DRDA EXCSQLSET command).
* In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the
SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the
coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET
statement [see note below].
* In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set;
if so, use it (by setting the timeout value on the server-side Statement
object before calling execute/executeQuery).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
[ http://issues.apache.org/jira/browse/DERBY-506?page=all ] Oyvind Bakksjo updated DERBY-506: - Attachment: DERBY-506_PRE.diff This patch is not intended for inclusion, it just illustrates the idea and is a basis for discussion about the approach. The patch enables setQueryTimeout() for prepared update statements in the client driver. Implement Statement.setQueryTimeout in the Client Driver Key: DERBY-506 URL: http://issues.apache.org/jira/browse/DERBY-506 Project: Derby Type: New Feature Components: JDBC Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Attachments: DERBY-506_PRE.diff Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver does not. The Client Driver should be enhanced and match the Embedded Driver. For this, we need to transfer the timeout value from the client to the server, preferably without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we need to extend the Derby grammar; only the Network Server needs to understand this DRDA EXCSQLSET command). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
Oyvind Bakksjo (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-506?page=all ] Oyvind Bakksjo updated DERBY-506: - Attachment: DERBY-506_PRE.diff I'd like to get some feedback on this approach. Since the DRDA protocol doesn't have any field for the query timeout, it's a bit of a hack (the approach is described in the JIRA issue). The patch itself is very small and simple, so please have a look if you're interested. All feedback is appreciated. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Resolved: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo resolved DERBY-579: -- Resolution: Fixed Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.diff, DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-587) Providing JDBC 4.0 support for derby
[ http://issues.apache.org/jira/browse/DERBY-587?page=comments#action_12331272 ] Oyvind Bakksjo commented on DERBY-587: -- OK, I'll commit it. Providing JDBC 4.0 support for derby Key: DERBY-587 URL: http://issues.apache.org/jira/browse/DERBY-587 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Fix For: 10.2.0.0 Attachments: jdbc4.0.sxw, jdbc40.diff, jdbc40.stat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
Satheesh Bandaram wrote: I am not exactly objecting :-) , but it would be nice to add a test case to show the problem the fix is attempting to fix. I suspect the original issue is easy to introduce, but hard to catch. I have made an attempt, but it is very hard to make a consistent reproduction of the issue. The reason is that when a statement is executed, the timeout value is immediately propagated (through the GenericPreparedStatement) to the StatementContext and the ResultSet. Therefore, the time window where this bug could affect other statements is very small. Also, this bug may only affect statements on different connections, since statements on the same connection may not execute simultaneously. As a result, in order to reproduce this issue, one needs to have the same statement executed simultaneously on many connections on a multi-cpu machine, and even then you'd probably hardly ever see it. By inserting a time-consuming no-op at the right spot in the engine I was able to reproduce it more frequently, but we cannot do that in testing. While we are on this topic, I noticed SetQueryTimeoutTest test takes around 30-40 minutes on my laptop. On one of our build machines, it actually runs for longer than 2 hours when the test harness actually kills the test. (causing the test to fail everytime) Though this is more of our test machine problem (it is really slw), taking 30-40 minutes for one functional test seems too long. Is there anyway the test can be made to run faster? It now runs in 29 seconds on my machine, I hope that's satisfactory. :) Satheesh -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
[jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo updated DERBY-579: - Attachment: (was: DERBY-579.svn.diff) Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo updated DERBY-579: - Attachment: (was: DERBY-579.svn.status) Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.diff, DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo updated DERBY-579: - Attachment: DERBY-579.svn.status Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.diff, DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=comments#action_12331188 ] Oyvind Bakksjo commented on DERBY-579: -- Last attached diff relates to svn repository version 293374. Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.diff, DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
Kathey Marsden wrote: Perhaps this is a silly idea, but would using a function in the query that had a sleep in it make this more predictable? 10 rows each with a sleep of 3 seconds guaranteed to take 30 seconds. It's not silly at all, it's in fact a very good idea. I have tried this approach and it works perfectly. Using this technique, I don't have to rely on big data volumes, so I should be able to squeeze the test's running time down to less than a minute, at the same time making it completely predictable on any hardware, fast or slow. Thanks for the great idea! -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
Satheesh Bandaram wrote: I am not exactly objecting :-) , but it would be nice to add a test case to show the problem the fix is attempting to fix. I suspect the original issue is easy to introduce, but hard to catch. While we are on this topic, I noticed SetQueryTimeoutTest test takes around 30-40 minutes on my laptop. On one of our build machines, it actually runs for longer than 2 hours when the test harness actually kills the test. (causing the test to fail everytime) Though this is more of our test machine problem (it is really slw), taking 30-40 minutes for one functional test seems too long. Is there anyway the test can be made to run faster? You realize that you are making conflicting requests, don't you? ;-) More tests in less time! I ran the test in 15 minutes, which is less than what you are experiencing, but I still think it is too much. I'll look into making the test run faster. The problem is that it's hard to tune the size of the tables so you're guaranteed that the fetching of some rows will take longer than the timeout value. I'll also look at adding a testcase for the bug that this patch addresses. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: VOTE: Require JUnit jar to build Derby, was: JUnit license, was: subversion etiquette
Rick Hillegas wrote: I would like to wrap up polling on this proposal by close of business Friday (San Francisco time). So far, no one has voted. Thanks, -Rick Rick Hillegas wrote: I would like to propose that we include JUnit as part of the required toolkit for Derby developers. Going forward, this will allow developers to write assertion-based tests. For the moment, this will not change the existing test harness. +1 -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: [jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
Oyvind Bakksjo (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo updated DERBY-579: - Attachment: DERBY-579.svn.diff If nobody objects by end of business today (any timezone), I will commit this patch. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: 10.1.2 Release status page
Daniel John Debrunner wrote: Francois Orsini wrote: Nightly builds should only be posted if regression tests have passed IMHO. I disagree, a nightly build is use at your own risk. Even if one test fails the jar may still work and allow anyone to test other areas. I think the nightly build should be the build used in the testing reported at http://www.multinet.no/~solberg/public/Apache/Derby/index.html/ That way, people can download and use a nightly build at their own risk, but they can also see what tests the build has passed/failed. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
[jira] Created: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assigned to: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo updated DERBY-579: - Attachment: DERBY-579.svn.status Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo updated DERBY-579: - Attachment: DERBY-579.svn.diff This patch fixes the bug as proposed by Dan Debrunner (pass the timeout into the execute method of org.apache.derby.iapi.sql.PreparedStatement, not store it as a field in GenericPreparedStatement.). jdbcapi test has been run without errors. Currently running derbyall. svn diff executed on revision 290453. Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.diff, DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-574) Per JDBC connection timeouts are incorrectly set on org.apache.derby.iapi.sql.PreparedStatement which represents a shared plan.
[ http://issues.apache.org/jira/browse/DERBY-574?page=all ] Oyvind Bakksjo closed DERBY-574: Fix Version: (was: 10.2.0.0) Resolution: Duplicate Per JDBC connection timeouts are incorrectly set on org.apache.derby.iapi.sql.PreparedStatement which represents a shared plan. --- Key: DERBY-574 URL: http://issues.apache.org/jira/browse/DERBY-574 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Reporter: Daniel John Debrunner The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. I think the solution is to pass the timeout into the execute method of org.apache.derby.iapi.sql.PreparedStatement, not store it as a field in GenericPreparedStatement. [from http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL PROTECTED] ] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Bug with query timeout
Daniel John Debrunner wrote: I think I just noticed an bug with the new query timeout function, I should have seen it during the review. The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. OK, I didn't know they could be used by multiple connections simultaneously. +1 on renaming the classes.. I guess the reason my test didn't catch this (it does simultaneous executes in order to check that the timeout effects only the right one) is that although the queries are essentially the same, different tables are used, thus leading to different plans/GenericPreparedStatement objects. I'll be away until Friday; if the issue is still open when I get back I'll look into fixing it. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: Comitter List
Jean T. Anderson wrote: OK, Derby committers, you all have karma to the db site module. Oyvind and Jeremy, please try your commit again and let me know. It worked for me now. -- Øyvind Bakksjø Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
[jira] Closed: (DERBY-544) Admin guide has wrong value for constant TRACE_RESULT_SET_CALLS
[ http://issues.apache.org/jira/browse/DERBY-544?page=all ] Oyvind Bakksjo closed DERBY-544: Resolution: Fixed Admin guide has wrong value for constant TRACE_RESULT_SET_CALLS --- Key: DERBY-544 URL: http://issues.apache.org/jira/browse/DERBY-544 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Trivial Fix For: 10.2.0.0 Attachments: DERBY-544.diff, DERBY-544.status The admin guide at http://db.apache.org/derby/docs/10.1/adminguide/cadminappsclienttracing.html lists the various tracing constants for the Network Client. It lists the value of the TRACE_RESULT_SET_CALLS constant as 0x3; the correct value is 0x4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-544) Admin guide has wrong value for constant TRACE_RESULT_SET_CALLS
[ http://issues.apache.org/jira/browse/DERBY-544?page=comments#action_12322775 ] Oyvind Bakksjo commented on DERBY-544: -- I'll go ahead and commit it. Admin guide has wrong value for constant TRACE_RESULT_SET_CALLS --- Key: DERBY-544 URL: http://issues.apache.org/jira/browse/DERBY-544 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Trivial Fix For: 10.2.0.0 Attachments: DERBY-544.diff, DERBY-544.status The admin guide at http://db.apache.org/derby/docs/10.1/adminguide/cadminappsclienttracing.html lists the various tracing constants for the Network Client. It lists the value of the TRACE_RESULT_SET_CALLS constant as 0x3; the correct value is 0x4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-544) Admin guide has wrong value for constant TRACE_RESULT_SET_CALLS
Admin guide has wrong value for constant TRACE_RESULT_SET_CALLS --- Key: DERBY-544 URL: http://issues.apache.org/jira/browse/DERBY-544 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assigned to: Oyvind Bakksjo Priority: Trivial Fix For: 10.2.0.0 The admin guide at http://db.apache.org/derby/docs/10.1/adminguide/cadminappsclienttracing.html lists the various tracing constants for the Network Client. It lists the value of the TRACE_RESULT_SET_CALLS constant as 0x3; the correct value is 0x4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-544) Admin guide has wrong value for constant TRACE_RESULT_SET_CALLS
[ http://issues.apache.org/jira/browse/DERBY-544?page=all ] Oyvind Bakksjo updated DERBY-544: - Attachment: DERBY-544.diff DERBY-544.status Admin guide has wrong value for constant TRACE_RESULT_SET_CALLS --- Key: DERBY-544 URL: http://issues.apache.org/jira/browse/DERBY-544 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Trivial Fix For: 10.2.0.0 Attachments: DERBY-544.diff, DERBY-544.status The admin guide at http://db.apache.org/derby/docs/10.1/adminguide/cadminappsclienttracing.html lists the various tracing constants for the Network Client. It lists the value of the TRACE_RESULT_SET_CALLS constant as 0x3; the correct value is 0x4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-463) Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the file pointer
[ http://issues.apache.org/jira/browse/DERBY-463?page=all ]
Oyvind Bakksjo resolved DERBY-463:
--
Fix Version: 10.2.0.0
Resolution: Fixed
Committed revision 233487.
Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the
file pointer
-
Key: DERBY-463
URL: http://issues.apache.org/jira/browse/DERBY-463
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.0.2.1
Environment: Sun java full version 1.4.2_05-b04
Linux x86
Derby is run in network server mode
Reporter: Laurenz Albe
Assignee: Fernanda Pizzorno
Fix For: 10.2.0.0
Attachments: DERBY-463.diff, DERBY-463.stat
I have a table
PEOPLE(SEQ_ID INT NOT NULL PRIMARY KEY, PICTURE BLOB).
A row is inserted; both values are not NULL.
From inside a JDBC program, I select the Blob for update.
I then get the Blob output stream with a call to
Blob.setBinaryStream(long)
To this stream I write several times with
OutputStream.write(byte[], int, int)
I close the stream, update the selected row with the new Blob and commit.
The new value of the Blob now is exactly the value of the last content of the
byte[],
and it is like the previous calls to write() have never taken place, or as if
the file pointer
of the output stream has been reset between the calls.
A sample program follows; the size of the input file picture.jpg is 23237,
the length
of the Blob after the program has run is 23237 % 1024 = 709
sample program -
import java.sql.*;
class TestApp {
private TestApp() {}
public static void main(String[] args)
throws ClassNotFoundException, SQLException, java.io.IOException {
// try to load JDBC driver
Class.forName(com.ibm.db2.jcc.DB2Driver);
// open the input file
java.io.InputStream instream = new
java.io.FileInputStream(picture.jpg);
// login to database
Connection conn = DriverManager.getConnection(
jdbc:derby:net://dbtuxe/testdb, laurenz, apassword);
conn.setAutoCommit(false);
// select Blob for update
PreparedStatement stmt = conn.prepareStatement(
SELECT PICTURE FROM PEOPLE WHERE SEQ_ID=? FOR UPDATE OF
PICTURE);
stmt.setInt(1, 1);
ResultSet rs = stmt.executeQuery();
// get Blob output stream
rs.next();
Blob blob = rs.getBlob(1);
java.io.OutputStream outstream = blob.setBinaryStream(1l);
// copy the input file to the Blob in chunks of 1K
byte[] buf = new byte[1024];
int count;
while (-1 != (count = instream.read(buf))) {
outstream.write(buf, 0, count);
System.out.println(Written + count + bytes to Blob);
}
// close streams
instream.close();
outstream.close();
// update Blob with new value
String cursor = rs.getCursorName();
PreparedStatement stmt2 = conn.prepareStatement(
UPDATE PEOPLE SET PICTURE=? WHERE CURRENT OF + cursor);
stmt2.setBlob(1, blob);
stmt2.executeUpdate();
// clean up
stmt2.close();
stmt.close();
conn.commit();
conn.close();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Created: (DERBY-505) Add system procedure to allow setting statement timeout
Satheesh Bandaram wrote: I agree with these comments... In fact, I added similar comments to the bug on 14th Aug. In case Jira didn't send that message out, here it is: I would like to hear reasoning behind this new feature request. I see following issues with the suggestion: 1) System procedures and functions are used for admin and diagnostic purposes typically. Since there is no standard for these, every database vendor has their own way to perform admin and diagnostics. However, this proposal seems to define application behavior based on system procedure. 2) I would like to know why JDBC's setQueryTimeout mechanism is not sufficient... Not sure what the bug comment means by query timeout functionality not only through JDBC, but also through SQL. Derby supports SQL only using JDBC currently. If the comment is refering to IJ, that is also a JDBC application and could be programmed to support query timeout using JDBC. Satheesh Mike Matrigali wrote: I am wondering why this is necessary, since there is a way to do this through jdbc - why add a different way to do this? I assume users could always create their own procedure if they needed it. What is the circumstance that you need this from SQL rather than JDBC. To me this just doesn't seem like the right use of the derby provided system procedures. We added the system utility system procedures as a last resort for the things which had no sql standard, like backup and import. Any use of system procedure is non-standard and will cause issues for database portability, so I think it is important to not add to them if it is not necessary. If there really is a need to do this from sql rather than jdbc I would prefer in the following order: 1) let users create their own procedure using existing available syntax 2) do the setting as a property rather than a system procedure Hi, Sorry for not getting back to you on this, I've been busy with other stuff the past couple of days. So, a little bit of history. In a previous email (http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED]), I suggested (on the side of the main topic) making query timeout available to SQL scripting through the use of a SET statement. (Making e.g. ij use the JDBC methods, such as Statement.setQueryTimeout(), would require it to parse the input.) In a following email (http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED]), Dan asked whether it could be done in a system procedure, rather than by adding new grammar. So I just wanted to propose it, since it would be really easy to implement if there is any interest in the functionality. It seems there isn't. ;o) I'll close the issue. -- Øyvind Bakksjø Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
[jira] Closed: (DERBY-505) Add system procedure to allow setting statement timeout
[ http://issues.apache.org/jira/browse/DERBY-505?page=all ] Oyvind Bakksjo closed DERBY-505: Resolution: Won't Fix No interest in this functionality. Use JDBC instead. Add system procedure to allow setting statement timeout --- Key: DERBY-505 URL: http://issues.apache.org/jira/browse/DERBY-505 Project: Derby Type: New Feature Components: SQL Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Propose to add a system procedure: SYSCS_UTIL.SYSCS_SET_STATEMENT_TIMEOUT(INT) This procedure will enable the query timeout functionality not only through JDBC, but also through SQL. I suggest the following semantics: The timeout value (in seconds) set with this procedure will apply to all subsequent statements executed on the current connection (the same connection on which the procedure was called), until a different value is set with the same procedure. A value of 0 indicates no timeout. Supplying a negative value will cause an exception. For each executed statement, the semantics are the same as for using Statement.setQueryTimeout() through JDBC. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-463) Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the file pointer
[
http://issues.apache.org/jira/browse/DERBY-463?page=comments#action_12319005 ]
Oyvind Bakksjo commented on DERBY-463:
--
The bugfix looks ok.
My comments do not concern the fix, but the patch itself:
- BlobOutputStream.java: The System.arraycopy() line's diff is just a different
ordering of subtraction and addition - same behaviour as before.
- blobclob4BLOB.java: A blank line removed, and an added javadoc header without
a function - should probably go into blobSetBinaryStream.java?
- blobSetBinaryStream.java:
* No newline at end of file
* The 'isDerbyNet' variable seems to be unused
* Do you need the 'startJBMS()' and 'setAutoCommit()' calls after the call to
testBlob1() in main()?
...and maybe this is a little picky, but:
* Some lines are not properly indented in main().
* Some typos in the string literals: setBinaryStram, mutiple (don't
forget to update the master file also).
You will usually catch things such ac unnecessary diffs yourself by looking
closely at the patch before submitting it. :)
Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the
file pointer
-
Key: DERBY-463
URL: http://issues.apache.org/jira/browse/DERBY-463
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.0.2.1
Environment: Sun java full version 1.4.2_05-b04
Linux x86
Derby is run in network server mode
Reporter: Laurenz Albe
Assignee: Fernanda Pizzorno
Attachments: DERBY-463.diff, DERBY-463.stat
I have a table
PEOPLE(SEQ_ID INT NOT NULL PRIMARY KEY, PICTURE BLOB).
A row is inserted; both values are not NULL.
From inside a JDBC program, I select the Blob for update.
I then get the Blob output stream with a call to
Blob.setBinaryStream(long)
To this stream I write several times with
OutputStream.write(byte[], int, int)
I close the stream, update the selected row with the new Blob and commit.
The new value of the Blob now is exactly the value of the last content of the
byte[],
and it is like the previous calls to write() have never taken place, or as if
the file pointer
of the output stream has been reset between the calls.
A sample program follows; the size of the input file picture.jpg is 23237,
the length
of the Blob after the program has run is 23237 % 1024 = 709
sample program -
import java.sql.*;
class TestApp {
private TestApp() {}
public static void main(String[] args)
throws ClassNotFoundException, SQLException, java.io.IOException {
// try to load JDBC driver
Class.forName(com.ibm.db2.jcc.DB2Driver);
// open the input file
java.io.InputStream instream = new
java.io.FileInputStream(picture.jpg);
// login to database
Connection conn = DriverManager.getConnection(
jdbc:derby:net://dbtuxe/testdb, laurenz, apassword);
conn.setAutoCommit(false);
// select Blob for update
PreparedStatement stmt = conn.prepareStatement(
SELECT PICTURE FROM PEOPLE WHERE SEQ_ID=? FOR UPDATE OF
PICTURE);
stmt.setInt(1, 1);
ResultSet rs = stmt.executeQuery();
// get Blob output stream
rs.next();
Blob blob = rs.getBlob(1);
java.io.OutputStream outstream = blob.setBinaryStream(1l);
// copy the input file to the Blob in chunks of 1K
byte[] buf = new byte[1024];
int count;
while (-1 != (count = instream.read(buf))) {
outstream.write(buf, 0, count);
System.out.println(Written + count + bytes to Blob);
}
// close streams
instream.close();
outstream.close();
// update Blob with new value
String cursor = rs.getCursorName();
PreparedStatement stmt2 = conn.prepareStatement(
UPDATE PEOPLE SET PICTURE=? WHERE CURRENT OF + cursor);
stmt2.setBlob(1, blob);
stmt2.executeUpdate();
// clean up
stmt2.close();
stmt.close();
conn.commit();
conn.close();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-463) Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the file pointer
Fernanda Pizzorno (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-463?page=all ] Fernanda Pizzorno updated DERBY-463: Attachment: DERBY-463.diff Change method write (byte[], int, int) in java/client/org/apache/derby/client/am/BlobOutputStream.java. offset_ was not being incremented. I'll review your patch. -- Øyvind Bakksjø Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
[jira] Created: (DERBY-503) Documentation should recommend using .newInstance() to instantiate JDBC driver
Documentation should recommend using .newInstance() to instantiate JDBC driver -- Key: DERBY-503 URL: http://issues.apache.org/jira/browse/DERBY-503 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Priority: Minor Using Class.forName(driver name).newInstance() is the recommended way to load and instantiate the JDBC driver, but the documentation does not contain the .newInstance() part. Pointers: http://db.apache.org/derby/docs/10.1/devguide/cdevdvlp40653.html http://db.apache.org/derby/docs/10.1/ref/rrefjdbc32052.html The EmbeddedDriver javadoc mentions it: The JDBC specification recommends the Class.ForName method without the .newInstance() method call, but adding the newInstance() guarantees that Derby will be booted on any Java Virtual Machine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-505) Add system procedure to allow setting statement timeout
Add system procedure to allow setting statement timeout --- Key: DERBY-505 URL: http://issues.apache.org/jira/browse/DERBY-505 Project: Derby Type: New Feature Components: SQL Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assigned to: Oyvind Bakksjo Priority: Minor Propose to add a system procedure: SYSCS_UTIL.SYSCS_SET_STATEMENT_TIMEOUT(INT) This procedure will enable the query timeout functionality not only through JDBC, but also through SQL. I suggest the following semantics: The timeout value (in seconds) set with this procedure will apply to all subsequent statements executed on the current connection (the same connection on which the procedure was called), until a different value is set with the same procedure. A value of 0 indicates no timeout. Supplying a negative value will cause an exception. For each executed statement, the semantics are the same as for using Statement.setQueryTimeout() through JDBC. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
Implement Statement.setQueryTimeout in the Client Driver Key: DERBY-506 URL: http://issues.apache.org/jira/browse/DERBY-506 Project: Derby Type: New Feature Components: JDBC Versions: 10.1.1.0 Reporter: Oyvind Bakksjo Assigned to: Oyvind Bakksjo Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver does not. The Client Driver should be enhanced and match the Embedded Driver. For this, we need to transfer the timeout value from the client to the server, preferably without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; conceptually a SET STATEMENT TIMEOUT seconds (this does not mean that we need to extend the Derby grammar; only the Network Server needs to understand this DRDA EXCSQLSET command). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
David Van Couvering wrote: Hi, Oyvind, you may have already done this, but can you linke this to DERBY-310? That was my intention, yes. Thanks for reminding me. :) Done now. -- Øyvind Bakksjø Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: Statement.setQueryTimeout() in client/server mode
Daniel John Debrunner wrote: [EMAIL PROTECTED] wrote: Currently, the Derby client contains a client-side implementation of setQueryTimeout; using a TimerTask to invoke Statement.cancel() on the client side. First of all, cancel() is not implemented, so this doesn't work. Furthermore, we should use the server-side mechanism we now have for statement timeouts. For this, we need to transfer the timeout value from the client to the server, preferable without a separate round-trip. I have some loose thoughts on how to do this: I'm not so sure, the reason is that the client side query timeout is performing additional or different work. The client side needs to timeout if the server has not responded within the given time, this includes communication problems between the client and server. So assume we have to fix the network communication problem, so the client times out and cancels the statement if it has no received no response from the server. Now if this is done, what is the advantage of also pushing the timeout value to the server? You now have two timeouts running, performing exactly the same operation. And most likely the client one will fire first as it is set up first. I would not say they perform exactly the same operation. The one on the server side stops the processing, causing statement rollback. The one on the client side just returns control to the application. I would think the application would be interested in knowing the transaction state after a statement timeout. Therefore, the server should time out the statement and throw an exception to the client. Otherwise, it might be that the statement successfully completes execution on the server side, but is cancelled on the client side before the result is returned. In this case, the client would get an exception, wrongfully indicating that the statement processing was cancelled when it in fact was not. This may result in erroneous client behaviour later, and thus, unexpected inconsistencies in the database (at the application semantic level). Alternatively, the client must use a different exception code on timeout, implying that the outcome of the last statement execution is unknown. Also, cancelling a statement only on the client side leaves the server processing the statement indefinitely. If your motivation for using setQueryTimeout() is to prevent runaway queries, this will not achieve what you want in client/server mode. I agree that detecting and handling communication problems between the client and server is necessary, but I don't think this is the responsibility of the query timer. A connection failure should not only terminate statements; the server will have to roll back uncommitted transactions, and the client knows this. So we need to separate connection failures from query timeouts. In the spirit of making Derby behave the same in both embedded and client/server mode (as far as possible - of course, connections may fail), I think the server's querytimeout mechanism should be used regardless of operating mode. -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Statement.setQueryTimeout() in client/server mode
Currently, the Derby client contains a client-side implementation of setQueryTimeout; using a TimerTask to invoke Statement.cancel() on the client side. First of all, cancel() is not implemented, so this doesn't work. Furthermore, we should use the server-side mechanism we now have for statement timeouts. For this, we need to transfer the timeout value from the client to the server, preferable without a separate round-trip. I have some loose thoughts on how to do this: * If the client has set a timeout value for a statement, prepend the (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the timeout value; e.g., SET STATEMENT TIMEOUT 10 (the actual wording is not important for this general discussion). * In DRDAConnThread.parseEXCSQLSETobjects() on the server side, recognize the SET STATEMENT TIMEOUT text, parse the timeout value and remember it for the coming EXCSQLSTT command. Do NOT invoke executeUpdate() with the SET statement [see note below]. * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has been set; if so, use it (by setting the timeout value on the server-side Statement object before calling execute/executeQuery). Note: Instead of having the SET STATEMENT TIMEOUT syntax be understood only by the Network Server, we could augment the Derby SQL grammar with such a vendor-specific feature. In that case, I think the timeout value should be considered session-wide; meaning, affecting all succeeding statements on the same connection, with the same value, until modified. This would support timeouts in SQL clients like ij. But this is not the important part. When going into details, we'll also need to consider the behaviour with batched statements and prepared versus unprepared statements (different DRDA commands are being sent from client to server), but at this early stage I would just like to get some feedback on these general ideas. -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Daniel John Debrunner wrote: Daniel John Debrunner wrote: Daniel John Debrunner wrote: I had to re-run the tests because the patch messed up on one file, but now StmtCloseFunTest fails for me with this patch. *** Start: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:08:57 *** 2a3 Statement Test failed (10) 4a6 Prepared Statement Test failed 7a10 Callable Statement Test failed Test Failed. *** End: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:09:05 *** I'll look into it, but is anyone else seeing this failure? This is because the setQueryTimeout used to throw a not implemented exception, but now succeeds. But in this case the statement is closed so according to the JDBC spec, all such methods should throw an exception. Oyvind, do you want me to commit your current patch (I've made the copyright date changes, and performed the svn adds and propsets) and then you could fix this problem quickly? I wouldn't want to check in anything that is known to cause tests to fail, even temporarily. The fix is very simple; adding a call to checkStatus() at the very top of EmbedStatement.setQueryTimeout() fixes the problem. If you want me to, I can submit a new patch, but I think the quickest approach would be if you just inserted the 'checkStatus()' call in your own sandbox. Sorry for not catching this one myself; there was a lot of complaining about broken builds and derbyall not running cleanly at the time, and I guess I was just a bit lazy... Won't *ever* happen again. ;o) -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Daniel John Debrunner wrote: I think delaying the comment is fine. I'm planning to commit this change before the end of this week, assuming all the tests run for me. Great! One thing I do need is confirmation that the copyright dates are correct in the files you've added. Some of them have dates of 1997,2004 which seems unlikely, are all the new files meant to have a copyright date of 2005? I can fix this if it is the case. Yes, 2005 is correct. I'm assuming that some performance tests will be run before this code makes it as part of a release, comparing performance to 10.1/10.0 and the performance impact of enabling query timeout. Yes, I certainly plan to do performance testing of this. rather than a new error XJ074.S, the existing generic error XJ081.S (added by Shreyas) could have been used. OK. Considering e.g. these existing codes (see below), it was not clear to me what was the preferred way - adding a separate code or using a generic one. String INVALID_FETCH_SIZE = XJ062.S; String INVALID_MAX_ROWS_VALUE = XJ063.S; String INVALID_FETCH_DIRECTION = XJ064.S; String INVALID_ST_FETCH_SIZE = XJ065.S; String INVALID_MAXFIELD_SIZE = XJ066.S; -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Daniel John Debrunner wrote: Oyvind Bakksjo (JIRA) wrote: Hi Dan, thanks for reviewing this patch so quickly. I am fully aware of and share you concern for the performance impact of creating all the TimerTask objects. It is far from ideal. The problem is that the Timer class _forces_ recreation of TimerTask objects, since these can't be reused; when a TimerTask has run or been cancelled, it is pure waste. Trying to schedule the same task again will cause an exception. If it wasn't for this, we could associate a TimerTask with each StatementContext object. This is the kind of case where a comment in the code helps a great deal. A comment that says why a new TimerTask is created each time due to the requirements of the Java timer scheme. Not everyone will know or remember restrictions on TimerTasks. Ane when I looked at the JDK 1.4 javadoc it wasn't clear to me that that was the intention of the scheme. The implication TimerTasks can not be re-used is hidden the exception description for adding one to Timer. I would almost read the javadoc as you can re-use timer tasks, but a timer task can not be scheduled multiple times concurrently. No, scheduling an already used TimerTask will generate an IllegalStateException if any of the following are true (I have verified this): a) the task has been scheduled but has not yet been run b) the task has been scheduled and has been run c) the task has been scheduled and has been cancelled In other words, TimerTask objects can be scheduled only once, they can not be reused. I suggest that I write a comment about this in the code in a subsequent patch (for instance when implementing Statement.cancel), unless anybody wants me to address this now and submit a new patch. -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Daniel John Debrunner wrote: Oyvind Bakksjo (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-31?page=all ] Oyvind Bakksjo updated DERBY-31: Attachment: DERBY-31.svn.status DERBY-31.svn.diff derbyall_report.txt Attached patch addresses the following issues: * Throw exception on negative input to setQueryTimeout() * Test case for the above * Use milliseconds instead of seconds in the PreparedStatement interface and GenericPreparedStatement class * Exclude SetQueryTimeoutTest from DerbyNet and DerbyNetClient, since these environments don't yet support the new functionality (will create a fix for the DerbyClient driver later I'll look at this again, before it can be committed you will need to have an ICLA on file at Apache. Ideally all contributors need to have ICLA's on file, at least any that are contributing more than minor changes. http://db.apache.org/source.html http://www.apache.org/licenses/#clas I signed and faxed the ICLA on May 19th, so that should be in order. -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Kathey Marsden wrote: [EMAIL PROTECTED] wrote: Shreyas, would you mind deleting the old patch to avoid confusion. Also I was thinking you might be interested in reviewing Oyvind's patch since you have shown interest in this issue in the past. Perhaps Oyvind would be willing to review your patch for DERBY-156 as well. Sure, I'll review it. -- yvind Bakksj Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12313431 ] Oyvind Bakksjo commented on DERBY-31: - Hi Dan, thanks for reviewing this patch so quickly. I am fully aware of and share you concern for the performance impact of creating all the TimerTask objects. It is far from ideal. The problem is that the Timer class _forces_ recreation of TimerTask objects, since these can't be reused; when a TimerTask has run or been cancelled, it is pure waste. Trying to schedule the same task again will cause an exception. If it wasn't for this, we could associate a TimerTask with each StatementContext object. This performance impact will, however, only affect queries with a timeout value set. As such, it is a tradeoff - you can get timeouts, but that will slow down your execution. If it turns out that the calls to checkCancellationFlag() seriously affect performance, these calls could be decimated by doing the call only for each n-th row. (It sure will be nice to get that performance regression test, so we'll see the actual impact.) For the time being, I can do some rudimentary testing of this myself. I agree a separate module for the timer might be overkill. As for the interface, my idea was that more methods than getCancellationTimer() could be added as needs arose for Timers for other purposes. It would be up to the implementing class whether to actually return the same Timer object. I guess it would depend on the duration of the TimerTasks and the responsiveness requirements whether to use multiple Timers or just a single one. I meant to support milliseconds use internally and seconds at the JDBC API level. I guess it would be more consistent if I used milliseconds in the language PreparedStatement interface as well. And yes, I'll fix throwing an exception on negative timeout values. Statement.setQueryTimeout() support. Key: DERBY-31 URL: http://issues.apache.org/jira/browse/DERBY-31 Project: Derby Type: New Feature Components: JDBC Environment: ALL Reporter: Ali Demir Assignee: Oyvind Bakksjo Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status Calling Statement.setQueryTimeout() throws exception saying that function is not supported. This is an important JDBC feature and is limiting our options to use Derby with our JDBC code. Implementing this JDBC function would make Derby much easier to adopt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ] Oyvind Bakksjo updated DERBY-31: Attachment: svn.diff Output of the 'svn diff' command. Statement.setQueryTimeout() support. Key: DERBY-31 URL: http://issues.apache.org/jira/browse/DERBY-31 Project: Derby Type: New Feature Components: JDBC Environment: ALL Reporter: Ali Demir Assignee: Oyvind Bakksjo Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status Calling Statement.setQueryTimeout() throws exception saying that function is not supported. This is an important JDBC feature and is limiting our options to use Derby with our JDBC code. Implementing this JDBC function would make Derby much easier to adopt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ] Oyvind Bakksjo updated DERBY-31: Attachment: svn.status Output of the 'svn status' command. Statement.setQueryTimeout() support. Key: DERBY-31 URL: http://issues.apache.org/jira/browse/DERBY-31 Project: Derby Type: New Feature Components: JDBC Environment: ALL Reporter: Ali Demir Assignee: Oyvind Bakksjo Attachments: Derby-31.patch, QueryTimer.java, svn.diff, svn.status Calling Statement.setQueryTimeout() throws exception saying that function is not supported. This is an important JDBC feature and is limiting our options to use Derby with our JDBC code. Implementing this JDBC function would make Derby much easier to adopt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
DERBY-31: setQueryTimeout patch submitted
I have attached a patch for Statement.setQueryTimeout() to the DERBY-31 JIRA issue. I hope somebody will have time to review it. I'm currently running derbyall, which seems to run fine, except that it takes very long on my machine, and I'm leaving for the weekend, so I will not have the time to attach its result until Monday. I think that shouldn't stop anyone from looking at the patch now. -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
