Javier Borrajo wrote:
> > 2. Keep in conversational state the ids of the first and last rows the
> user
> > is currently looking at, and re-issue the query every time he navigates.
> > Undesirable because of extra computation, plus gets complex if there is
> > sorting & grouping going on, or the table changes out from under the
> user.
>
> No good as Randy explains.
>
> > 5. Make the user refine his query to yield a smaller result set.
>
> Not practical or user-friendly.
>
> > In the FoodSmart example application on the Developer's Guide CD
> > (http://www.gemstone.com/javasuccess), the way we handle this is to read
> the
> > whole result set and cache it in GemStone's PCA. Then we give a
> > SearchResult entity bean back to the client, which allows random
> navigation
> > through the result set. This is an example of the search result as
> entity
> > bean pattern - see http://www.c2.com/cgi/wiki?SearchResultAsEntityBean.
>
> No good, this solution if wasting a lot of server resources.
>
[Randy Stafford] If the data being queried over is already
persistent in PCA, this does not waste any resources - it merely results in
the creation of a Collection whose elements are pointer references to
objects already persistent in the object database, and an entity bean to
wrap that collection, that implements behavior similar to what you describe
below. If the data being queried over doesn't persist in PCA, then yes,
this solution involves O/R mapping and caching the result in PCA - which is
probably not a good solution for very large tables.
> The average user
> does
> not really want to navigate around 100.000 rows, what we provide is
> something
> like this:
> + getCount(String) allows the client to submit a query
> and returns a count of how many records fit that query
> + getPage(String,int,int) allows the client to submit a query,
> a starting position and a pagesize and returns a page of records
>
> This simple scheme fits nicely with Swing components such as JList,
> JTable...
> A JList model will use "getCount" to answer the "getRowCount" question and
> then
> "getPage" to answer the "getElement" question depending on the user
> viewing
> area,
> no need to serialize the whole resultset or keep any state at the server.
> The client caches 2-3 pages of data to allow the user for scrolling.
> Usually the user makes a general query, sees how many thousands of records
> fit the query, then redefines the query until he or she gets the right
> data.
>
[Randy Stafford] So in effect, aren't you doing a combination of 2
and 5, above - re-issuing the query and making the user refine his query,
both of which you acknowledged as "no good"?
> The client keeps the state, i.e. the client knows what query to perform
> (including sorting and grouping etc) and also where to start and how many
> records
> to get back.
>
[Randy Stafford] In our solution the client keeps the state as
well, in terms of where in the result set snapshot the user is currently
navigating. Without a snapshot, how do you handle the case where the table
changes out from under the user in between his navigations? Especially with
sorting and grouping, this could result in a disconcerting user experience.
Randy
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
