From derby-dev-return-26255-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Tue Aug 08 20:49:00 2006 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 30210 invoked from network); 8 Aug 2006 20:48:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Aug 2006 20:48:59 -0000 Received: (qmail 20851 invoked by uid 500); 8 Aug 2006 20:48:59 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 20816 invoked by uid 500); 8 Aug 2006 20:48:58 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 20807 invoked by uid 99); 8 Aug 2006 20:48:58 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Aug 2006 13:48:58 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Aug 2006 13:48:58 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 34EF241000C for ; Tue, 8 Aug 2006 20:46:15 +0000 (GMT) Message-ID: <9352747.1155069975214.JavaMail.jira@brutus> Date: Tue, 8 Aug 2006 13:46:15 -0700 (PDT) From: "Craig Russell (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network In-Reply-To: <7606451.1153080613822.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426707 ] Craig Russell commented on DERBY-1516: -------------------------------------- Hi Dan, Thanks for your comments. > I mean comments clarifying the length & position arguments passed in and the valid ranges etc. Though while you were in there you could see if the description was correct, e.g. EmbedClob.getSubString() says: > NOTE: return the empty string if pos is too large > which I don't think is true before or after your changes. I think I understand your comments and will try to update the comments to reflect reality. > Why length +1, why not > length? If 0 < pos <= length, then there is no way to get any bytes (even zero bytes) from a 0-length blob. And I don't believe that this is the intent. Nor is it consistent with what other vendors have implemented. There is no loss of functionality in the "length + 1" behavior. If your position is length + 1, then you can only get zero-length results from it. And this is exactly the case of a zero-length Lob. The title of this issue is "inconsistent behavior for embedded versus network". So something's gotta give. And after looking at it in detail, I'm convinced that the right behavior is to be consistent with regard to getBytes and getSubString; with regard to zero-length and non-zero-length Lobs; and with regard to embedded versus network. And this patch does it. > Inconsistent behavior for getBytes and getSubString for embedded versus network > ------------------------------------------------------------------------------- > > Key: DERBY-1516 > URL: http://issues.apache.org/jira/browse/DERBY-1516 > Project: Derby > Issue Type: Bug > Components: JDBC > Reporter: Craig Russell > Assigned To: Craig Russell > Priority: Minor > Attachments: DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch > > > org.apache.derby.client.am.Clob.getSubString(pos, length) and org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for less than zero. > if ((pos <= 0) || (length < 0)) { > throw new SqlException(agent_.logWriter_, "Invalid position " + pos + " or length " + length); > But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less than or equal to zero. > if (length <= 0) > throw Util.generateCsSQLException( > SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length)); > The specification does not disallow length of zero, so zero length should be allowed. I believe that the implementation in org.apache.derby.client.am is correct, and the implementation in org.apache.derby.impl.jdbc is incorrect. -- 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