FWD » Core Development » Database

While working on #11027, I found a test case which behaves wrong in FWD:

find last test6_8971.
test6_8971.f1 = test6_8971.f1 + 1.

def buffer b_test6_8971 for test6_8971.
for each b_test6_8971 by f1 desc:
    message  b_test6_8971.f1.
end.

As a requirement, test6_8971 needs to have a few records. Then, I am incrementing f1 on the last record, then iterating over the records in DESC mode. Unfortunately, the for each doesn't return any results.

Basically, the query is early invalidated, so the offEnd is initally set on OffEnd.FRONT. However, as it is iterated in DESC mode, in RAQ.findNext, it computes the offend as OffEnd.BACK, and returns null;

After a discussion with Alex, a solution may be to try to also call query.first inside this block from BlockManager.forEachWorker:

            do
            {  
               try
               {  
                  if (!query.next())
                  {
                     wa.tm.notifyCondition(Condition.ENDKEY);
                     try
                     {
                        wa.tm.processOffEndListeners(true);
                        // avoid roll-back; the query initialization might have done some database work
                        // like honoring the RecordNursery. If the query didn't find any record, using a rollback
                        // will eliminate the work done in the init block (i.e. a side-effect aggressive flush).
                        break loop;
                     }
                     finally
                     {
                        wa.tm.processOffEndListeners(false);
                     }
                  }
                  topQuerySuccessful = true;

                  if (processForBody(wa, block, to, expr, on, defOn))
                  {
                     break loop;
                  }
               }

After a discussion with Alex, a solution may be to try to also call query.first inside this block from BlockManager.forEachWorker:

I have my doubts about this idea. For example, what if we are dealing with a RETRY scenario caused by the ENDKEY? We can't call the query processing directly from this location if it is aa RETRY. Please provide more details on why adding query.first() is the solution.

Also, we need to prove this with testcases. I worry that there are many ENDKEY cases that don't force the first record to be loaded.