Hi Markus,
yup, I also figured out the test case is ok. I did some debugging and
running on oracle and derby the Query result as returned by
query.getResultList() has 12 elements.
Regards Michael
> 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
>>>
>>
>