Strange behaviour of the rangeSize - or is it desired?

Question

Hi there,
as recently asked in Difference between VO Fetch Size, Iterator rangeSize and af:table Fetch Siz we have a problem with the rangeSize property of the iterator binding.
First of all, we're currently working wit JDev version 11.1.2.2.0. So, we have a page with a table. In this table is nested inside a panel collection which is nested inside a panel stretch layout. To cut a long story short, it stretches.
The rangeSize is now set to the default 25, but you could see in the fullscreen usage about 35 rows. When we now select a row which is in the rage of the first 25 records and use the data in such a method:
RichTable table = this.getTable();
RowKeySet rowKeySet = table.getSelectedRowKeys();
Iterator selectetNodesIterator = rowKeySet.iterator();
CollectionModel treeModel = (CollectionModel)table.getValue();
JUCtrlHierBinding treeBinding = (JUCtrlHierBinding)treeModel.getWrappedData();
while (selectetNodesIterator.hasNext()) {
  List selectedRowKeyPath = (List)selectetNodesIterator.next();
  JUCtrlHierNodeBinding nodeBinding = treeBinding.findNodeByKeyPath(selectedRowKeyPath);
  Row row = nodeBinding.getRow();
  DBSequence aaId = (DBSequence)row.getAttribute("AaId");
}We got a NPE at Row row = nodeBinding.getRow();, because the nodeBinding is null. Only the last fetched records have a JUCtrlHierNodeBinding.
So yeah ok, for testing purposes we changed the rangeSize to 1, just to see what happens. And again it fetches one row after another as long is the tables current view is full. And if we try it again every record results in a NPE excpet the very last visible record. So far so good, after what we've seen with 25 records this was expected.
When we change the rangeSize to a value greater than 36 (the visible rows, in that current fullscreen resolution) it works as it should.
So, to see if there is a bug i decided to create a small testapp with the HR schema. I've just dropped the employees vo as a table inside a panel collection which is nested inside a panle stretch layout. And used nearly the same method:
public String onButtonClicked() {
  RowKeySet rks = table.getSelectedRowKeys();
  CollectionModel tablemodel = (CollectionModel)table.getValue();
  JUCtrlHierBinding binding = (JUCtrlHierBinding)tablemodel.getWrappedData();
  Iterator it = rks.iterator();
  while(it.hasNext()){
    List selectedRowKeyPath = (List)it.next();
    JUCtrlHierNodeBinding node = binding.findNodeByKeyPath(selectedRowKeyPath);
    Row row = node.getRow();
    System.out.println("Testausgabe: " + row.getAttribute(1));
  return null;
}When the rangeSize is now set to 1 every visible row except the last also result in a NPE. If we run that above code on a button click, but now the strange part. When the rangeSize is changed to a value greater 1 it works like a charm. You can run that code with every visible record an you get now NPE. Also very strange with a rangeSize = 1, when you select the last visible record which is working and run the code, then select a record above, which had thrown an NPE previously and run the code. It is working, but with the value of the last visible record.
This leads us to a bunch of questions.
1) Is it the supposed way to work, that you get a NPE when the rangeSize is set to a smaller number than visible rows?
2) If 1) is the desired way, how do you handle the rangeSize for a table which is stretched? You couldn't now how many rows you could see.
3) Does anyone have an idea how to explain the last explained behaviour with the testapp? (I could upload it)
Thanks in advance.
Alex

Answer 1

Hi Alex,
can you open a SR at Oracle support for this issue?
I know there are several bugs which are somehow related with the rangeSize and the synchronization of the model (currrent row) and the view (in this case the visible part of af:table).
See also Restore current row after rollback does not work with page ranging
As far I know Oracle plans some enhancements in this area to fix the syncronize problems and change e.g. the rangeSize dynamically depending on the number of rows visible in the GUI.
But anyway your issue sounds like a new bug.
regards
Peter