objectbridge-developers

[OJB-developers] cursor control

[Matthew B. <ma...@so...>]

I'm currently working on some rudimentary cursor control for ODMG. I want to
outline my approach and solicite some feedback:

1. Creation of an EnhancedOQLQuery interface that includes:
		void create(String queryString, int startAtIndex, int
endAtIndex) throws QueryInvalidException;
	int fullSize();

2. have OQLQueryImpl implement both OQLQuery and EnhancedOQLQuery.

3. create(String, int, int) creates a query that uses the resultsets
underlying cursor to return results starting at startAtIndex, and ending at
endAtIndex, thus being the most efficient way to return results for a "page"
of data.

4. fullSize() returns the actual size the query returns, based on using the
underlying resultsets cursor to move rows instead of iterating through. If
you have a start and end index, it will still return how many rows the query
would have returned if you hadn't limited it.

GOALS:
- Backward compatibility. If you don't want this functionality, don't change
your code and it will continue to work exactly as before.
- Maximum efficiency for building a paged result set of many items. In our
application we have to display the classic (1-10 of 100,002,040) paged
result set. If we had to iterate through the results materializing objects
(even proxies) it could take all day to display one page. Using the query to
limit the number of returned objects or just displaying 1-10 of LOTS! Is not
an option as the last number is important for the user.
- improve performance of OJB by only using scrollable resultsets if the user
needs them.

I currently DO NOT like the names I made for getting the size on the
underlying query. Please comment on what they should be.

I have a full test suite for the implementation that stresses every
combination of startAtIndex/endAtIndex and size.

Please send me your thoughts. Thanks
Matthew

Re: [OJB-developers] cursor control

[Thomas M. <tho...@ho...>]

Hi Matthew,

Matthew Baird wrote:

 > I'm currently working on some rudimentary cursor control for ODMG.


good idea!

 >I want to
 > outline my approach and solicite some feedback:
 >
 > 1. Creation of an EnhancedOQLQuery interface that includes:
 > 		void create(String queryString, int startAtIndex, int
 > endAtIndex) throws QueryInvalidException;
 > 	int fullSize();
 >


ACK


 > 2. have OQLQueryImpl implement both OQLQuery and EnhancedOQLQuery.
 >


ACK


 > 3. create(String, int, int) creates a query that uses the resultsets
 > underlying cursor to return results starting at startAtIndex, and 
ending at
 > endAtIndex, thus being the most efficient way to return results for a 
"page"
 > of data.


ACK
How does it work internally? Are you using
PersistenceBroker.getIteratorByQuery(...)? How do you manage to start at
a given index?


 >
 > 4. fullSize() returns the actual size the query returns, based on 
using the
 > underlying resultsets cursor to move rows instead of iterating 
through. If
 > you have a start and end index, it will still return how many rows 
the query
 > would have returned if you hadn't limited it.


ACK


 >
 > GOALS:
 > - Backward compatibility. If you don't want this functionality, don't 
change
 > your code and it will continue to work exactly as before.
 > - Maximum efficiency for building a paged result set of many items. 
In our
 > application we have to display the classic (1-10 of 100,002,040) paged
 > result set. If we had to iterate through the results materializing 
objects
 > (even proxies) it could take all day to display one page. Using the 
query to
 > limit the number of returned objects or just displaying 1-10 of LOTS! 
Is not
 > an option as the last number is important for the user.
 > - improve performance of OJB by only using scrollable resultsets if 
the user
 > needs them.
 >
 > I currently DO NOT like the names I made for getting the size on the
 > underlying query. Please comment on what they should be.


What about something like:
rowCount()
elementCount()
actualRowCount()
actualElementCount()


 >
 > I have a full test suite for the implementation that stresses every
 > combination of startAtIndex/endAtIndex and size.
 >


that's a real plus!

I think a paging query is a very useful thing not only for the ODMG
implementation but also for the PersistenceBroker.


cheers,

Thomas


 > Please send me your thoughts. Thanks
 > Matthew
 >
 > _______________________________________________________________
 >
 > Don't miss the 2002 Sprint PCS Application Developer's Conference
 > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 >
 > _______________________________________________
 > Objectbridge-developers mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
 >
 >
 >
 >