PF12 Bug: headerTable and summaryTable cause excessive calls to load() in the LazyModel

[giemes1]

With the update to PF12, we have noticed strange behavior when using the
dataTable with headerRows and summaryRows.

load() in the LazyModel gets called with shifting "first" and "pageSize"
params, which we traced back to the "isInSameGroup(...)" method in the
DataTableRenderer (starting at line 1670), called twice per row in
"encodeRows(...)", once for header and once for summary.

The line has the following comment: "in case of a lazy DataTable, the
LazyDataModel currently only loads rows inside the current page; we need
a small hack here"

The "small hack" consists of a call to the model's "getRowData(int, Map,
Map)", which then calls load(...) with strange parameters: "first" being
the "rowIndex" (assuming you want to load a specific row from the
underlying data source, namely the one before or after the target row
with the step constants -1 and +1) and a page size of "rowIndex + 1",
which would cause exceptionally large page sizes with higher row indices
(?).

Before PF12, the LazyDataModel abstract class would only call load(...)
predictably once in the initial render and once per pagination event, so
our implementation cached the parameters and returned the wrapped data
when they were identical to the already fetched data, and would
otherwise populate some state variables and trigger callbacks for our
post-load processing. I assumed load() should only be called when a
database operation is to happen. Your JpaLazyDataModel seems to make the
same assumption, as it doesn't seem to cache anything.

The new calls to load(...) just to fetch the next or previous row for
isInSameGroup() checks breaks with that established behavior and seems
excessive, as a call is made twice for every row, just to fetch data
that has already been fetched in the page for all rows except the first
and last, and even then a dedicated call to load() just to fetch the
rows behind and ahead the current page and determine their grouping
status seems inefficient.

Is this truly intended? Either I adapt our DataModel to try and detect
these bogus load(...) calls and try to redirect them to the loaded data,
or overwrite the renderer to make isInSameGroup() refer to the loaded
data that is in the current page, and return "false" otherwise
(displaying the header and summary even on page breaks would be
acceptable to only have one database call instead of three). The only
other option is not to use headerRows and summaryRows at all.

Perhaps this behavior could be refined or at least be made configurable?

[Melloware]

Did you try in PF 13.0.0 i believe this issue has been fixed.

[giemes1]

Hi,

We just gave PF13.0.0 a try and found that the behaviour is still the same as described above for PF12 (specifically PF12.0.5).

There still are two calls to the model's "getRowData" and thus "load" for every row (from "isInSameGroup"). So, unfortunately, our problem persists with PF13.0.0.

Thnx for having a look into it!

regards, Gerd

[Melloware]

Please open a Github ticket with your reproducer!

I feel like your issue is related to: https://github.com/primefaces/primefaces/issues/6169