Michael,
you are definitively right! Following the official description of
setMaxResults in the EJB 3.0 JPA specification, the SQLAnywhere driver
is working absolutely correct, while the expected result in the test is
false!
So I will file a bug report for that.
Thanks a lot!
Markus
Michael Bouschen schrieb:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>