Pagination strategies - LargeSelect, a work in progress

[Scott Eade <se...@backstagetech.com.au>]

I am looking at org.apache.turbine.util.db.LargeSelect (t2.1, in torque it
is  org.apache.torque.util.LargeSelect) with a view to using it for my
paging needs.  As this was discussed very recently (refer to the earlier
Pagination strategies thread) I thought a few of you may be interested in
how this is coming along.

As I am apparently the first user of LargeSelect I am having lots of fun
(not!) debugging it and extending it to suit my needs.

Here are a few of the problems I have run into so far along my solutions and
dead ends:

1. In LargeSelect.run() it is necessary to initialise the results Vector (do
the conversion to ArrayList in your head for torque).
2. In LargeSelect.run() it is necessary to invoke qds.clearRecords() to
recycle the QueryDataSet at the end of the while loop that retrieves the
records.
3. Even though LargeSelect accepts a name (and provides a default) to use as
the key to use to store itself in the session it does not do the storing.  I
have just been sticking it in user.temp as this seems as good a place as
any.
4. I am sort of used to the Peer classes populating the select columns
automatically, this does not occur with LargeSelect so you may want to
invoke your peer class addSelectColumns(criteria) method before
instantiating a LargeSelect.  Of course it is better in these situations to
only retrieve the minimum of columns, a way to do this is mentioned shortly.
5. LargeSelect returns village Record objects, while manageable, there is a
better way of dealing with this.  I have created a new interface,
org.apache.turbine.util.db.Populatable (again, do the conversion to
org.apache.torque.util in your head for torque) that defines a
populateObject(Record, int) method and added a constructor to LargeSelect
that includes a String argument that defines a class name that implements
Populatable.  I can then create a class, e.g. UserListItem, that implements
Populatable which provides the mapping from a village Record to an instance
of the class (I will be working towards bending this to allow the regular
Peer classes to be used here, but these will require some modification - the
populateObject() method provided by the peers is a Static and I am unsure
how I can tell if this is available on an arbitrary class).
6. LargeSelect cannot currently provide any information as to how many
results in total will be returned.  I am working on an extension class,
LargeNumeratedSelect that provides this information however I am running
into the following problems:
    a) The Criteria class doesn't allow addSelectColumn("COUNT(*)") without
modification.
    b) MySQL won't allow "COUNT(*)" in a query without a GROUP BY clause
(this seems crazy to me - all I want to know is how many rows are returned
by the query, I am pretty sure that DB2 and Oracle allow this).
    c) The Turbine 2.1 Criteria class does not support GROUP BY so I can
implement a workaround that adds a dummy constant column to group by.
This means that I effectively have to abandon support for
LargeNumeratedSelect until I move to the decoupled torque (been holding back
so far because of my need to extend TurbineUser).
7. Other issues exist - I am only currently scratching the surface.

I'll keep plodding along.  Once I get somewhere I will port my changes
forward to the decoupled torque and post a patch.  This won't have been
tested using torque, but neither has the current class anyway.  For that
matter I may as well include my untested LargeNumeratedSelect class.  If
somebody working with the decoupled torque wants to work with me on this we
may get somewhere much faster.

Cheers,

Scott
-- 
Scott Eade
Backstage Technologies Pty. Ltd.
Web: http://www.backstagetech.com.au



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>