dev@glassfish.java.net

Re: setFirstResult in conjunction with setMaxResults returns too much results

From: Michael Bouschen <Michael.Bouschen_at_Sun.COM>
Date: Fri, 05 Jan 2007 16:27:27 +0100

Hi Markus, hi Tom,

please correct me if I'm wrong, but I think returning 13 instances for
the third test is the correct query result. The description of method
setMaxResult in the spec says: "Set the maximum number of results to
retrieve.". I read this that setMaxResult specifies the size of the
query result and not the index of the last result element. The third
test case calls query.setFirstResult(2) and query.setMaxResults(14). So
it is specified to return at most 14 instances. But there are only 13
rows left when firstResult is specified as 2 (the numbering starts at 0).

What do you think?

Regards Michael

> Hi Markus,
>
> There has actually been some recent discussion on the mailing list
> about setFirstResult() and setMaxResult(). Here's how they work:
>
> The current implementation of setFirstResult() and setMaxResult() make
> use of JDBC constructs rather than RDBMS constructs.
>
> For setMaxResult() we call the java.sql.Statement.setMaxRows(int) method.
>
> For setFirstResult() we make use of the ResultSet that is returned in
> JDBC. If firstResult is set, we build query that returns a
> TYPE_SCROLL_INSENSITIVE ResultSet and call resultSet.absolute(int) on
> that result set.
>
> Is it possible the result for the SQLAnywhere driver is not what we
> expect?
>
> -Tom
>
>
> Markus KARG wrote:
>
>> When I was implementing the SQLAnywhere platform I remarked a failing
>> test: complexResultPropertiesTest. That test tries three things:
>> setFirstResult, setMaxResult and a combination of both. The used
>> table holds 15 row. The first test (setFirstResult(2)) return 13 rows
>> (what is correct, since 15-2=13). The second test
>> (setMaxResults(15-1)) returns 14 rows (what is correct, since
>> 15-1=14). But the third test fails. The correct result would be to
>> return 12 rows (= 15-2-1). But the actual result is 13 rows!
>>
>> I have not seen any faulty SQL (in fact, it seems that TopLink does
>> this internally -- it does not apply any "SELECT TOP START AT" range
>> constraints to the SQL, but seems to process the range constraints
>> internally.
>>
>> So did I detect a bug in TopLink, or where is there a fault in my
>> platform implementation?
>>
>> Thanks
>> Markus
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>