db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Query startAt endAt
Date Fri, 21 Nov 2003 17:02:12 GMT
hi wallace,

PagingIterator had a problem with size() anyway.

jakob

Gelhar, Wallace Joseph wrote:
> Jakob,
> 
> The IndexOutOfBounds was my mistake.  My wrapper layer was setting the offset to a default
of 0 instead of 1.
> 
> Wally
> 
> -----Original Message-----
> From: Gelhar, Wallace Joseph [mailto:GELHARWJ@uwec.edu] 
> Sent: Thursday, November 20, 2003 1:50 PM
> To: OJB Developers List
> Subject: RE: Query startAt endAt
> 
> 
> Hi Jakob,
> 
> I've just stumbled on a bug when getCollectionByQuery returns an empty collection.  The
underlying iterator throws a IndexOutOfBoundsException.  I'll dig some more when I get a chance.
> 
> Thanks,
> 
> Wally
> 
> -----Original Message-----
> From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch] 
> Sent: Thursday, November 20, 2003 1:31 PM
> To: OJB Developers List
> Subject: Re: Query startAt endAt
> 
> 
> hi wallace,
> 
> thanks for the hint. javadoc is now up-to-date.
> 
> jakob
> 
> Gelhar, Wallace Joseph wrote:
> 
>>Hi Jakob,
>>
>>I wanted to let you know about a change in behavior introduced with
>>this with respect to the inclusive set.  Previously, using 
>>setStartAtIndex(1) and setEndAtIndex(11) would return rows 1-10 
>>(startAt inclusive, endAt exclusive).  Now the same query makes the 
>>endAt inclusive retrieving rows 1-11.  I think you should make a note 
>>of this in the javadoc.
>>
>>I do appreciate all your hard work.  Keep up the good work.
>>
>>Thanks,
>>
>>Wally
>>
>>-----Original Message-----
>>From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
>>Sent: Wednesday, November 19, 2003 3:25 PM
>>To: OJB Developers List
>>Subject: Re: Query startAt endAt
>>
>>
>>hi wallace,
>>
>>PagingIterator is now checked in .
>>
>>jakob
>>
>>Jakob Braeuchi wrote:
>>
>>
>>
>>>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
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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


Mime
View raw message