Kevin and Mike:
This comes back to the issue I was raising earlier this week regarding
parameterized dataTables. There are a number of cases where it would be
nice to be able to set some values for use by the backing bean when it
is invoked by the dataTable tag. In this case, being able to specify a
'start' and 'number of rows' value would make the ResultSet more manageable.
It seems to me that the current dataTable tag has the assumption that
the backing bean will hand it a complete result set and that is what is
to be displayed. This is OK as far as it goes (and from a pure object
perspective, makes sense) but there seems to be a disconnect between the
handling of large result sets and this model. The disconnect comes from
our desire not to consume so much system resource. The fact that there
is no way to limit the size of the result set other than in a static
manner - that is, the limits to the result sets are hard-coded in the
backing bean - severely restricts how dataTable may be used.
At a minimum, it would be nice to have parameters for start and number
of rows that could be set for the dataTable. In a larger sense, it would
be nice to be able to specify any set of name/value pairs that the
backing bean could then use as it saw fit. You could even have a new
dataTable type, say dynamicDataTable, to address this if it made more sense.
-david-
Kevin Galligan wrote:
"...value binding for the whole set of data". 10,000 rows, at a
maximum, or literally millions of rows? I guess I don't understand
what you're really looking for. If you want to keep the results in
session, yeah, they're in memory. Not millions of rows. Just
whatever your search results are. If you don't want to keep them in
memory you can try using the resultset datamodel implementation, which
I assume is not ripping through the whole result set and building a
version in memory or anything.
I don't know how resultset keeps its data. I probably should figure
that out considering my chosen profession.
If you're going to be working with huge results to link to data, this
might not be your best method. At results of that size, if this will
be a well traveled system, you might want to use something a little
more low level and link that into your faces code.
However, 10,000 row result reports is begging for a different design,
IMHO.
Dave wrote:
Normally we have filters to select a portion of data from database
table. But it can be very large too. For example, searching found
10,000 items. For the backend, ResultSet will have the 10,000
records. I am trying to understand how the ResultSet manages the
10,000 records. It would consume lots of memory if all of them in
memory. For dataTable scroller, I still need to provide value binding
for the whole set of data.
*/Kevin Galligan <[EMAIL PROTECTED]>/* wrote:
Out of curiosity, how are you planning to use the millions of
rows? I
would assume you'd want to filter them in some way rather than
attempt
to display them, right? That would kind of answer your question
(your
datatable would only have the filtered results. Not the full table).
Mike Kienenberger wrote:
> Data fetching would depend on your backing Collection.
>
> You can use t:dataScroller to limit the dataTable to accessing
only a
> subset of the data.
>
> I'd love to see a t:liveGridDataTable component like what's
available
> at this site, but I suspect it's currently outside of my
ability to
> implement.
>
> http://openrico.org/rico/livegrid.page
>
> On 9/8/05, Dave wrote:
>
>>For a large database table that has millions of records(rows),
how is the
>>memory managed from backend to ? all the millions of records
>>are in memory? That would crash the system. Is the collection(
returned from
>>database layer) actually not filled with data until they are
requested ?
>>Thanks. Dave
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
------------------------------------------------------------------------
Click here to donate to the Hurricane Katrina relief effort.
<http://store.yahoo.com/redcross-donate3/>
