db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agsoftware.dnsalias.com>
Subject Re: Query startAt endAt
Date Sun, 16 Nov 2003 21:11:10 GMT
Jakob Braeuchi dijo:
> hi all,
>
> armin and i are currently working on supporting sql pageing (aka LIMIT).
>   OJB provides it's own way of paging using startAt and endAt indices in
> query. the problem i have now is the meaning of endAt.
>
> ie: startAt = 2, endAt = 5 -> OJB retrieves _3_ object at 2, 3, 4
>
> is this really the correct behaviour ? imo we should return _4_ objects
> (2 through 5).

Yep. You need to return 4 rows (5 included).

> another issue is the way dbms implement the LIMIT parameters. most of
> them use an _offset_ and a _number_ of rows to return. some of them only
> the number of rows. should we change ojb to support offset/number or do
> we stay with startAt/endAt ?

Personally, I prefer LIMIT and OFFSET approach. Try to explain:

StartAt = OFFSET
endAt = OFFSET + LIMIT

But:

"endAt" indicates that it need to end at a given index. But this index
does not necesary exists. Suppose 5 row in a table and we use:

startAt = 1, endAt = 10

The "endAt" index never will be reached. For me the endAt in this case
does not exactly describe what we are requesting.

On the other hand:

startAt = 1, limit = 10 => This is correct, it means we will start at 1
and we will retrieve at max 10 rows. But there is not an implicit index of
the  last one. Also using limit= 10 avoid us to doing some innecesary
"maths". We cleary express the max. amount of rows we expect to recieve in
a very easy way. It is easier from a programming view. You will not need
to sum the 2 values to get the endAt value.

I just tried to explain my view point. Of course, comments are welcome. :-D

Best Regards,

Antonio Gallardo

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message