Return-Path: 
 <dev-return-21592-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org>
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 5211 invoked from network); 13 Dec 2006 11:29:23 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 13 Dec 2006 11:29:23 -0000
Received: (qmail 99977 invoked by uid 500); 13 Dec 2006 11:29:17 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 99948 invoked by uid 500); 13 Dec 2006 11:29:17 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@harmony.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@harmony.apache.org>
List-Post: <mailto:dev@harmony.apache.org>
List-Id: <dev.harmony.apache.org>
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 99934 invoked by uid 99); 13 Dec 2006 11:29:17 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Dec 2006 03:29:17 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of oleg.v.khaschansky@gmail.com
 designates 66.249.82.230 as permitted sender)
Received: from [66.249.82.230] (HELO wx-out-0506.google.com) (66.249.82.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Dec 2006 03:29:07 -0800
Received: by wx-out-0506.google.com with SMTP id i26so142568wxd
        for <dev@harmony.apache.org>; Wed, 13 Dec 2006 03:28:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=YjxTYsSDB/vVEzeu2nhyW1lvmIQx3nN6xXvUqH1Mdd8WMpORXB5p44883NvCkYckOY5QTMG/oGMditmrswn6F9tpYC9Hz/B1uChU/lmRJip3IlHfGRZtl+l5pYT5iXUwTphwCieiQDJPn6dOCvYGW+kEgicGHEcl7NCvgouqyOM=
Received: by 10.90.35.15 with SMTP id i15mr505399agi.1166009327095;
        Wed, 13 Dec 2006 03:28:47 -0800 (PST)
Received: by 10.90.71.13 with HTTP; Wed, 13 Dec 2006 03:28:47 -0800 (PST)
Message-ID: <26c14c2a0612130328h1c7b137er2d206fa42a923e18@mail.gmail.com>
Date: Wed, 13 Dec 2006 14:28:47 +0300
From: "Oleg Khaschansky" <oleg.v.khaschansky@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][sql] RI's bug of SerialBlob.position(byte[] pattern,
 long start)?
In-Reply-To: <4d0b24970612130124t45cf3264q77bb52d42d212fa6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4d0b24970612120021y1f6b97d2v6801798dd2b01161@mail.gmail.com>
	 <26c14c2a0612120644w3541fea2s3d6d061f335d9120@mail.gmail.com>
	 <4d0b24970612130124t45cf3264q77bb52d42d212fa6@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

I am not a guru, but my understanding is that RI behavior is
errorneous. I'd say that from the client point of view BLOBs are just
byte arrays. I suggest to do exact search instead of following RI.

On 12/13/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> On 12/12/06, Oleg Khaschansky <oleg.v.khaschansky@gmail.com> wrote:
> >
> > I experimented a bit with this test. It looks like RI is doing following:
> > if all the bytes from the pattern occured in the blob in the same
> > sequence as in the pattern (possibly with any other bytes between
> > them)
>
>
>  Is it reasonable?
> Should Harmony follow RI's behaviour? Or just find the exact byte array in
> blob data?
> Could  jdbc/db gurus give some suggestions? Thanks a lot in adavance!
>
> then it returns <the position where it found the last byte from
> > the pattern> - (<the pattern length> - 1).E.g. if the blob contents is
> > 1,3,9,1,1,3,2,2,4,2,3,9,3,3 and the
> > pattern is 1,2,3 then it takes the position of the third occurence of
> > 3 (after 1 and 2 occured) and subtracts 2 (the pattern length - 1)
> > from it. Then the return value is 9.
> >
> > This behavior of RI seems to be undocumented and illogical.
> >
> > On 12/12/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> > > Hi folks,
> > >
> > > I found that RI's behaviour of SerialBlob.postion(byte[] pattern, long
> > > start) looks strange. Consider following code:
> > >
> > >     private void testPosition_BytePattern()
> > >             throws SerialException, SQLException {
> > >
> > >         byte[] buf = { 1, 2, 3, 4, 5, 6, 7, 8 };
> > >         SerialBlob blob = new SerialBlob(buf);
> > >
> > >
> > >         byte[]  pattern = new byte[] { 2, 4 };
> > >         long pos = blob.position(pattern, 1);
> > >         // FIXME: RI's bug?
> > >         assertEquals(-1, pos);
> > >
> > >     }
> > >
> > > It tries to find pattern "2,4" from blob with data "1,2,3,4,5,6,7,8". RI
> > > returns 3 instead of -1. Spec says the method "returns the position in
> > this
> > > SerialBlob object where the given pattern of bytes begins, starting the
> > > search at the specified position. "and "position numbering for the
> > return
> > > value starts at 1".
> > >
> > > Did I misunderstand the spec? Or it's a bug of RI? Thanks!
> > > --
> > > Best regards,
> > > Andrew Zhang
> > >
> > >
> >
>
>
>
> --
> Best regards,
> Andrew Zhang
>
>