Would this proposal implicate in performance degradation over a local
environment, compared with what we have today ? As the pager would have to
connect and execute the command every time the pager moves to the next or
previous pages ?
If we could come up with same interface for connected and disconnected
pagers, maybe we could have a pager factory that you would instantiate
either one, connected pager (current version) or disconnected pager (what
you are proposing). This could give us a better flexibility and we would
leave the decision to the api consumer, where he would balance his
performance needs...
Toughts ?
On 11/8/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
The RDB DAS currently has a simple paging capability that is implemented
by wrapping a Command. Here is a simple example:
// Build command to read all customers
Command readCustomers = das.createCommand("select * from
CUSTOMER order by ID");
// Create a pager with page size 15
Pager pager = new PagerImpl(custCommand, 15);
// Get and work with first page
DataObject root = pager.next();
// Get and work with the second page
root = pager.next();
// First page again
root = pager.previous();
This works well if the client of the page data is on the server but not
so well if the client is not. The reason is that the pager wraps a
command instance which, in turn, references a connection. For a pager
to work in a "disconnected" mode it should probably be serializable and
very lightweight (it might be stored in session for instance) and it
cannot count on the original connection to be available. I think this
could easily be achieved by removing the instance variable from the
pager that references it's command. Instead, the command can be passed
as an argument to the paging methods like this:
DataObject root = pager.next(someReadCommand);
Does this sound reasonable?
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
