This happens in ADF also.
I got embarrassed today saying to a developer 'RTFM' and been proven wrong. So I will first post some parts of the javadoc of RowIterrator and then a test case that proves it wrong.
When a Row Iterator is first opened or created, the currency is placed on an imaginary "slot" before the first row. This enables the user to invoke next() on a fresh new Row Iterator and retrieve the first row. For example, the following block of code will print attribute "Ename" for all employees (it does not miss the first row):
ApplicationModule myAM;
...
ViewObject myVO = myAM.findViewObject("MyEmpVO");
Row row;
while ((row = myVO.next()) != null)
{
System.out.println("Ename: " + row.getAttribute("Ename"));
}
void reset()
Moves the currency to the slot before the first row.
After this method, the current slot status will be SLOT_BEFORE_FIRST except in cases where this iterator is associated to an iterator binding in an ADF application which sets the currency to the first row in the iterator if available. A subsequent invocation of next() will cause the first row to become the current row.
So I created a View Object that only gets 3 rows and a method in application module that iterrates according to the above descriptions through the iterator and return the rows visited in a string:
public String checkIterations() {
String res = "Iterated through : ";
RowIterator view = this.getDepartmentsView1();
view.reset();
Row row;
while ((row = view.next()) != null) {
System.out.println("rownum: " + row.getAttribute("RowNum"));
res += row.getAttribute("RowNum") + " ";
}
return res;
}
When I run Application nodule and test this method, it goes through all rows as expected.
But if I open the view object (execute query) and then run this method again, the first row is never visited.
So is this a bug?
Test Case:
http://adfbugs.googlecode.com/files/TestIterator.zip
As my friends in the comments said its not a bug
Its a bad development practice (development bug) to do it as described above.
I should say RATFM (readh all the f... manual):
9.7.6 What You May Need to Know About Programmatic Row Set Iteration
Any time your application logic accesses a row set to perform programmatic iteration, you should use a secondary row set iterator when working with view object instances in an application module's data model, or view link accessor row sets of these view object instances, since they may be bound to user interface components.
To create a secondary iterator, use the createRowSetIterator() method on the row set you are working with. When you are done using it, call the closeRowSetIterator() method on the row set to remove the secondary iterator from memory.
Example 9-7 shows a typical application module custom method that correctly uses a secondary row set iterator for programmatic iteration, because the EmpView1 view object instance in its data model may be bound to a user interface (either now or at a later time).
Example 9-7 Using a Secondary Row Set Iterator in an Application Module Custom Method
// Custom method in an application module implementation classpublic
void doSomeCustomProcessing() {
ViewObject vo = getEmpView1();
// create secondary row set iterator with system-assigned name
RowSetIterator iter = vo.createRowSetIterator(null);
while (iter.hasNext()) {
Row r = iter.next();
// Do something with the current row.
}
// close secondary row set iterator
iter.closeRowSetIterator();}
