Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <3FBBDC5E.2070807@gmx.ch>
Date: Wed, 19 Nov 2003 22:10:54 +0100
From: Jakob Braeuchi <jbraeuchi@gmx.ch>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: Query startAt endAt
References: <FEBBF51AFF7B8B4B8A2F32F6E63092AE106845@COKE.uwec.edu>
In-Reply-To: <FEBBF51AFF7B8B4B8A2F32F6E63092AE106845@COKE.uwec.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

hi wallace,

Gelhar, Wallace Joseph wrote:

> Hi jakob,
> 
> I figured out why paging was not working for my setup, although I'm not sure I understand.  It turns out that using p6spy as the driver did not allow the query to return any results when startAtIndex > 0 (corresponds with rs.absolute(int)).  I thought that p6spy was simply a wrapper and should not affect the query.  This is fine except parts of my app will be broken while I am trying to trace.  I'll survive.
> 

i think i have no problems with p6spy and mapping.

> BTW, there was some talk of making endAtIndex inclusive and/or changing the terminology to offset and limit.  Is this a method name / behavior change you plan on implementing before OJB goes to a release branch?
> 

the paging iterator will not cause a change of the interface of the 
query. if we do change it the behaviour will stay as it is today.

the methods could be:

-setPagingLimit
-setPagingOffset

jakob

> Thanks,
> 
> Wally
> 
> -----Original Message-----
> From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch] 
> Sent: Wednesday, November 19, 2003 12:21 PM
> To: OJB Developers List
> Subject: Re: Query startAt endAt
> 
> 
> hi wallace,
> 
> the current implementation (aka OJB-paging) work for 
> getCollectionByQuery only. the start-offset is used to position the 
> cursor of the resultset (rs.absolute()).
> but this only works for jdbclevel >= 2.0
> 
> the new implementation of OJB-paging will use a paging iterator to wrap 
> the original iterator, so it works for iterators as well but it still 
> needs jdbclevel >= 2.0
> 
> hth
> jakob
> 
> 
> Gelhar, Wallace Joseph wrote:
> 
>>Hi Jakob,
>>
>>Will you elaborate on how the current paging works?  What are the 
>>driver / platform requirements to make it work?
>>
>>I ask because I have never gotten paging to work for startAtIndex > 0.
>>
>>My platform is WinXP / Tomcat 4.1 / MS SQL Server 2K / MS JDBC Driver.
>>
>>My extremely crude hack is too retrieve an iterator and count the 
>>index to materialize the relevant objects.
>>
>>Any suggestions?
>>
>>Wally Gelhar
>>
>>-----Original Message-----
>>From: "Jakob Br�uchi" [mailto:jbraeuchi@gmx.ch]
>>Sent: Tuesday, November 18, 2003 9:09 AM
>>To: thma@apache.org
>>Cc: ojb-dev@db.apache.org
>>Subject: Re: Query startAt endAt
>>
>>
>>hi all,
>>
>>i have to inform you, that paging by SQL is not yet an option :( 
>>because we execute a select for each extent. but i think i found a way 
>>to improve OJB-paging be it for collections or iterators.
>>
>>as soon as time permits i will start working on the new solution.
>>
>>
>>jakob
>>
>>
>>
>>>Hi Jakob
>>>
>>><snip>
>>>
>>>>>Personally, I prefer LIMIT and OFFSET approach. Try to explain:
>>>>
>>>>
>>>>i also prefer the OFFSET and LIMIT.
>>>
>>>+1
>>>
>>>cu,
>>>Thomas
>>>
>>>
>>>
>>>>we do have a problem with dbms only
>>>>supporting OFFSET (oracle, sapdb etc.) there is a way to solve this
>>>>problem by using an enclosing query:
>>>>
>>>>select * from
>>>>(
>>>> select ... , rownum as ojb_rnum where .... order by ...
>>>>) where ojb_rnum between OFFSET and OFFSET + LIMIT
>>>>
>>>>
>>>>jakob
>>>>
>>>>
>>>>
>>>>
>>>>>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
>>>>>
>>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------
>>>>-
>>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For 
>>>>additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


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