[#4063] - Provide way to randomly access data source

Feature request
Project: Severity:
No Change Required
Component: Reproducibility:
Assigned to:

It would be generally helpful to be able to find
- if this row is first, last, etc.;
- what is the value of field X in last row; has it changed or not, etc.;
- what is the value in the next row.

Currently JR imposes strictly sequential way of data processing on reports. Some of these questions are possible to answer with custom variables, but these are tiresome to create and tweak in each next report (not to mention usecases like "average over 5 last values", which are generally a nightmare). Meanwhile, according to SortedDataSource source, JR already has all necessary information in memory, properly sorted. It only lacks a way to be accessed.

For example, $F{field X{-1}} could be the syntax to access value of a field in the previous row. It would be totally OK if this syntax required some additional preparation (e.g. report being sorted) and fail with an exception otherwise.

Naturally, existing syntax would remain the standard and normally used way of writing exception and people would resort to the proposed extension only if needed.

doublep's picture
Joined: Jun 26 2008 - 9:59pm
Last seen: 3 years 1 month ago


  • Status:New» Feedback Requested
  • Assigned:» teodord


The use of SortedDataSource internally in the JR engine is only triggered when sort fields are used, which means the data is cached on first pass.
But if there is no sort field defined in the dataset, JR will not cache and will not sort anything, which means it will not consume memory unnecessary.

I mention this because you said JR already has all the information needed. It has it, but only under certain circumstances and the report creator needs to understand the implications when using the feature.

Thank you,

  • Resolution:Open» No Change Required
  • Status:Feedback Requested» Resolved


I think that triggering the caching of the data on the first pass using a sort field based on the REPORT_COUNT built-in variable, so that the original order of the records is not affected, would be enough to perform complex calculations and direct data access on the SortedDataSource object.
Using an utility class to leverage the API which has SortedDataSource object at the top should be a fairly simple way to achieve any kind of data processing during report execution.

So I'm closing this one now.