Project

General

Profile

Actions

Bug #84779

closed

QueryInterface->execute() should do a rewind() before returning to avoid mismatch between content and count

Added by Stefan P about 6 years ago. Updated about 4 years ago.

Status:
Rejected
Priority:
Should have
Category:
Extbase
Target version:
-
Start date:
2018-04-18
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

It is possible to create situations in which the QueryResult content of a repository mismatches the QueryResult->count(). This seems to happen in statement() mode (writing raw SQL) and can also occur in language overlays (when not all or even none of the objects are translated). In these situations it is possible that, after the initial (raw or L=0) query is done, some objects are removed from the result (L>0 does not exist or enable fields are applied to the result from the raw statement), but the internal count is not updated then.

This is especially problematic for empty QueryResults that are presented as non-empty. In consequence <f:if condition="{queryResult}"> can return true for empty results or $queryResult->count() can mismatch. Doing f:debug (or a regular Extbase var_dump) on such a QueryResult shows the object as non-empty, but as soon as one tries to open the list of items it's empty.

Using the QueryResult only in a foreach loop does not have this problem, as the rewind is done implicitly then, though the \Iterable interface, but all non-\Iterable actions acting on the count() can behave weird.

In our projects we adopted to always doing ->rewind() before returning from the Repository find method. But ideally this should happen already in the execute() method automatically as the very last action before returning to ensure consitency between content and counter.

This happens in TYPO 7 and 8.

Actions

Also available in: Atom PDF