Michael,
I checked it again -- sorry I did a typo: It is 15 results in common,
then applying setFirstResult(2) in conjunction with setMaxResults(12)
but not (14) as I write before -- but I am getting still 13 results,
which is one more than twelve. So actually it is NOT a bug in the unit
test, but a bug somewhere in TopLink or in the JDBC driver.
Tom, can you please write five short code lines what you want me to
check with the JDBC driver?
Thanks
Markus
Markus KARG schrieb:
> 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
>>
>