Expected behaviour of DBDictionary.indexOf()?

[Alan Raison <Al...@luminary.co.uk>]

Hi

I noticed in the source of DBDictionary that the indexOf function will
have what I would consider to be unexpected behaviour when a start index
is specified.

When a start index is specified (say "N"), the search target string has
the first N characters removed, the search performed (by INSTR in the
default case), this is reduced by 1 to make it 0-indexed and then
crucially the start index in added to the result.

In Oracle, if the search term is not found, INSTR returns 0.  If a start
index is supplied, this is then added and 1 is taken away, so the
"result of indexOf" will be "start index - 1" if the search string is
not found.

I would expect the case where the string is not found to return 0 or -1,
depending on the index base.  I think it is misleading for this to
return a positive integer if the string is not found.  Would you agree?
I was going to raise a bug in JIRA for this, but I didn't know whether
it *is* expected behaviour.

The indexOf method is the same in OpenJPA 1.2.0 and 2.0

Alan Raison

Re: Expected behaviour of DBDictionary.indexOf()?

[Michael Dick <mi...@gmail.com>]

IMHO indexOf() should return -1 if the string isn't found (like
java.lang.String). This seems like a good candidate for a JIRA to me. I
don't think I'd want it introduced to a service stream as it's more of a
code cleanup issue.

If you don't mind using your newly created JIRA account please do create an
issue, and thanks!

-mike

On Fri, Jan 23, 2009 at 6:43 AM, Alan Raison <Al...@luminary.co.uk>wrote:

> Hi
>
> I noticed in the source of DBDictionary that the indexOf function will
> have what I would consider to be unexpected behaviour when a start index
> is specified.
>
> When a start index is specified (say "N"), the search target string has
> the first N characters removed, the search performed (by INSTR in the
> default case), this is reduced by 1 to make it 0-indexed and then
> crucially the start index in added to the result.
>
> In Oracle, if the search term is not found, INSTR returns 0.  If a start
> index is supplied, this is then added and 1 is taken away, so the
> "result of indexOf" will be "start index - 1" if the search string is
> not found.
>
> I would expect the case where the string is not found to return 0 or -1,
> depending on the index base.  I think it is misleading for this to
> return a positive integer if the string is not found.  Would you agree?
> I was going to raise a bug in JIRA for this, but I didn't know whether
> it *is* expected behaviour.
>
> The indexOf method is the same in OpenJPA 1.2.0 and 2.0
>
> Alan Raison
>