Michael Bouschen schrieb:
> 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
Thanks, good to know, but how to fix it in the SQLAnywhere platform? In
fact I have no idea what part of a DatabasePlatform implementation is
playing a role here.
Markus
>
>> 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
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>