db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: [Fwd: [PATCH] Derby-157 Patch, plus 2 other minor server fixes.]
Date Thu, 24 Mar 2005 19:07:06 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for the reminder. I have submitted this patch. I am wondering if
previously failing test cases should be added to Network server tests.<br>
<br>
Satheesh <br>
<br>
Sending&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; java\drda\org\apache\derby\impl\drda\DRDAConnThread.java<br>
Transmitting file data .<br>
Committed revision 158935.<br>
<br>
Army wrote:<br>
<blockquote cite="mid42430291.5060707@sbcglobal.net" type="cite">Committers,
  <br>
  <br>
I submitted this rather simple patch three weeks ago, but it looks like
it fell through the cracks.&nbsp; I'm re-attaching a
  <br>
newly created version of the patch (against the most recent codeline).
  <br>
  <br>
This is a fix for DERBY-157.&nbsp; I ran the derbynetmats suite with these
changes and there were no failures.&nbsp; As all changes in this patch are
specific to the Network Server, I don't think any other tests need to
be run.
  <br>
  <br>
Could someone please commit?
  <br>
  <br>
Thanks,
  <br>
Army
  <br>
  <br>
-------- Original Message --------
  <br>
Subject: [PATCH]&nbsp; Derby-157 Patch, plus 2 other minor server fixes.
  <br>
Date: Thu, 03 Mar 2005 16:05:09 -0800
  <br>
From: Army <a class="moz-txt-link-rfc2396E" href="mailto:qozinx@sbcglobal.net">&lt;qozinx@sbcglobal.net&gt;</a>
  <br>
Reply-To: Derby Development <a class="moz-txt-link-rfc2396E" href="mailto:derby-dev@db.apache.org">&lt;derby-dev@db.apache.org&gt;</a>
  <br>
To: Derby Development <a class="moz-txt-link-rfc2396E" href="mailto:derby-dev@db.apache.org">&lt;derby-dev@db.apache.org&gt;</a>
  <br>
  <br>
Attached is a patch that does the following three (pretty minor)
things:
  <br>
  <br>
1) First and foremost, it resolves DERBY-157.&nbsp; If a datetime string
that is not recognized by the server is received
  <br>
from the client, the server will now catch the resultant Java exception
and throw a valid SQLException with SQLSTATE
  <br>
22007 ("The syntax of the string representation of a datetime value is
incorrect").&nbsp; The old behavior was to throw a
  <br>
DRDA protocol exception and deallocate the connection.
  <br>
  <br>
2) It corrects a small problem in the way the server treats timestamp
strings.&nbsp; This problem, like DERBY-157, only
  <br>
happens with non-JCC clients: users who insert a timestamp value into a
Derby table by binding a _string_ value (ex.
  <br>
"1948-04-08 02:24:48") to a _timestamp_ parameter will actually get a
different value back when they do a SELECT because
  <br>
the value is 'warped' by the server before insertion.&nbsp; In particular,
extra 0's are added to the end of the string--ex.
  <br>
"1948-04-08 02:24:48000"--which are then treated as seconds when the
server calls java.sql.Timestamp.valueOf(), and thus
  <br>
the wrong value is inserted.
  <br>
  <br>
This doesn't happen with JDBC drivers because the code in question is
only executed when a _string_ value is being bound
  <br>
to a _Timestamp_ parameter--basically, the user would have to do
something like
  <br>
  <br>
ps.setTimestamp(1, "1948-04-08 02:24:48")
  <br>
  <br>
--but JDBC doesn't allow that, because the second argument has to be a
Timestamp object.&nbsp; With an ODBC client, though,
  <br>
this kind of thing is possible, and so this problem should be fixed.
  <br>
  <br>
3) It removes an extraneous call to "finalizeChain()" that was
introduced as part of the "Multiple EXCSAT fix" patch
  <br>
(see
<a class="moz-txt-link-freetext" href="http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200501.mbox/%3c41EF3DC3.6030407@Sourcery.Org%3e">http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200501.mbox/%3c41EF3DC3.6030407@Sourcery.Org%3e</a>).&nbsp;
This
  <br>
extra call doesn't lead to any bad behavior, but since it is
unnecessary and technically incorrect, it's good to remove
  <br>
it.&nbsp; It's a simple one-line removal, so if no one minds, I figure it
can be made with this patch, since all of the
  <br>
changes in this patch are to the same file and they are all pretty
minor.
  <br>
  <br>
In terms of tests, I haven't modified or added any test cases because
these are problems that can only be seen with a
  <br>
non-Java driver--and as far as I know, the current Derby test harness
has no means of introducing such a driver.
  <br>
  <br>
I have run the derbynetmats suite (on Windows using jdk142) with these
very minor changes and all tests passed.
  <br>
  <br>
Committers, please commit when you can...
  <br>
  <br>
Thanks,
  <br>
Army
  <br>
  <br>
  <br>
  <br>
  <pre wrap="">
<hr size="4" width="90%">
Index: java/drda/org/apache/derby/impl/drda/DRDAConnThread.java
===================================================================
--- java/drda/org/apache/derby/impl/drda/DRDAConnThread.java	(revision 158925)
+++ java/drda/org/apache/derby/impl/drda/DRDAConnThread.java	(working copy)
@@ -806,7 +806,6 @@
 				case CodePoint.EXCSAT:
 					parseEXCSAT();
 					writeEXCSATRD();
-					finalizeChain();
 					break;
 				case CodePoint.ACCSEC:
 					int securityCheckCode = parseACCSEC();
@@ -4039,7 +4038,17 @@
 				String paramVal = reader.readStringData(10).trim();  //parameter may be char value
 				if (SanityManager.DEBUG) 
 					trace("ndate parameter value is: \""+paramVal+"\"");
-				ps.setDate(i+1, java.sql.Date.valueOf(paramVal));
+				try {
+					ps.setDate(i+1, java.sql.Date.valueOf(paramVal));
+				} catch (java.lang.IllegalArgumentException e) {
+					// Just use SQLSTATE as message since, if user wants to
+					// retrieve it, the message will be looked up by the
+					// sqlcamessage() proc, which will get the localized
+					// message based on SQLSTATE, and will ignore the
+					// the message we use here...
+					throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+						SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+				}
 				break;
 			}
 			case FdocaConstants.DRDA_TYPE_NTIME:
@@ -4047,20 +4056,37 @@
 				String paramVal = reader.readStringData(8).trim();  //parameter may be char value
 				if (SanityManager.DEBUG) 
 					trace("ntime parameter value is: "+paramVal);
-				ps.setTime(i+1, java.sql.Time.valueOf(paramVal));
+				try {
+					ps.setTime(i+1, java.sql.Time.valueOf(paramVal));
+				} catch (java.lang.IllegalArgumentException e) {
+					throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+						SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+				}
 				break;
 			}
 			case FdocaConstants.DRDA_TYPE_NTIMESTAMP:
 			{
-				// DB2 represents ts with 26 chars, and a slightly different format than Java standard
-				// we do the conversion and pad 3 digits for nano seconds.
+				// JCC represents ts in a slightly different format than Java standard, so
+				// we do the conversion to Java standard here.
 				String paramVal = reader.readStringData(26).trim();  //parameter may be char value
 				if (SanityManager.DEBUG)
 					trace("ntimestamp parameter value is: "+paramVal);
-				String tsString = paramVal.substring(0,10)+" "+paramVal.substring(11,19).replace('.',
':')+paramVal.substring(19)+"000";
-				if (SanityManager.DEBUG)
-					trace("tsString is: "+tsString);
-				ps.setTimestamp(i+1, java.sql.Timestamp.valueOf(tsString));
+				try {
+					String tsString = paramVal.substring(0,10) + " " +
+						paramVal.substring(11,19).replace('.', ':') +
+						paramVal.substring(19);
+					if (SanityManager.DEBUG)
+						trace("tsString is: "+tsString);
+					ps.setTimestamp(i+1, java.sql.Timestamp.valueOf(tsString));
+				} catch (java.lang.IllegalArgumentException e1) {
+				// thrown by Timestamp.valueOf(...) for bad syntax...
+					throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+						SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+				} catch (java.lang.StringIndexOutOfBoundsException e2) {
+				// can be thrown by substring(...) if syntax is invalid...
+					throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+						SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+				}
 				break;
 			}
 			case FdocaConstants.DRDA_TYPE_NCHAR:

  </pre>
</blockquote>
</body>
</html>


Mime
View raw message