Project

General

Profile

Support #4063

linking looping FIND FIRST/NEXT and FIND LAST/PREV in a set oriented operation

Added by Greg Shah about 5 years ago. Updated about 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

History

#1 Updated by Greg Shah about 5 years ago

Can FIND FIRST and FIND NEXT with same buffer and same WHERE be matched together into a set oriented approach? Especially if the next is in a loop?

The same idea would work for FIND LAST and FIND PREVIOUS.

#2 Updated by Greg Shah about 5 years ago

From Constantin:

An idea here is to add an UUID at conversion time, to a FIND. This way the runtime can uniquely identify a FIND, and if it gets executed multiple times with the same arguments, we can switch it to a mode where it retrieves first 1 record, then 10, then 100, etc. This would be similar to what the DynamicResults (I think) does today,and it switch back to RandomAccessQuery if something happens (what AdaptiveQuery does today).

This 'FIND query registry' would get cleaned up when the internal procedure/function/external program terminates (or maybe just when the external program gets deleted, if the FIND is in an internal procedure/function).

#3 Updated by Greg Shah about 5 years ago

From Eric:

Yes. This has been implemented since 2006 as AdaptiveFind.

It doesn't detect that it is in a loop, if that loop is separated from the FIND NEXT by a top level block boundary, but that level of refactoring probably would be a solution looking for a problem.

#4 Updated by Greg Shah about 5 years ago

After speaking with Eric, some thoughts:

  • The current approach is handled exclusively at runtime.
  • The more advanced linking was not done because of the need for call-graph.

I think we can link these at runtime, avoiding the need for call-graph processing. The call-graph approach is not foll-proof anyway because it can be hidden deep in the call stack, far from the original usage. This is similar to the idea in #3194.

If the runtime knows enough about the WHERE clause, the substitution parameter values last used and whether any changes would have invalidated the results, then this can be calculated within a single user's session. We should already be able to tell that the same buffer is used in multiple places since each location has a reference to the buffer.

Also available in: Atom PDF