Bug #11501
Investigate useSnapshot usage in multi-table indexed-reposition queries
0%
Related issues
History
#1 Updated by Alexandru Lungu about 2 months ago
- Assignee set to Alexandru Lungu
This task is dedicated for investigating how the useSnapshot array shall be used in the context of an invalidate multi-table query (CQ) that is in indexed-reposition state. Use-snapshot is meant to be used to snapshot the outer-most records used by the query in the joining process. Components joined are evaluated using snapshots of the DMOs at the time the component fetched the record and not the actual image of the DMO in-memory or tracked.
To mimic this, FWD does a snapshot of the stored reference row (the peak of the cursor) and is used when bypassing the cursor limits in order to dynamically query new records.
In case of an indexed-reposition query, there are two peaks (the front and the end of the random-access cursor). In this case, the useSnapshot may need to have two variants - the snapshots saved at the front of the query and the snapshots saved at the back of the query. This is in line with how the random-access cursor works: storing two reference rows, one for each end.
Currently, trunk uses only the back-end reference-row in the use-snapshot computation. This is not evidently wrong. It is just that the DMO that is used for joining on the front-end will be selected under the same criteria as the back-end.
ATM, the use-snapshot unit tests are not passing anyway for normal scrolling queries, so the prerequisite effort on this task is to make adaptive tests pass in regard to use-snapshot feature for trivial cases. After this, we can compute a battery of tests for the same scenario, but applied to indexed-reposition queries
#2 Updated by Alexandru Lungu about 2 months ago
- Related to Bug #10962: Optimized multi-table compound components are not invalidated added