Bug #85241
closedQueryBuilder has no possibility to unset RestrictionContainers
0%
Description
ConnectionPool::getConnectionByName('Connection')::createQueryBuilder()
injects the DefaultRestrictionContainer
. The method resetRestrictions()
also does this.
The DefaultRestrictionContainer includes Deleted, Hidden, Starttime and Endtime. While these Restrictions are useful on the Default connection most of the time (even here not always), they are not useful on foreign connections. Of course, in a connection to a non-TYPO3 database these restriction usually do nothing, because $GLOBALS['TCA']
(which these restrictions check against) does not have an entry for a foreign table.
However, when connecting to a database of another TYPO3 installation (or if one explicitly wants deleted = 1
), this is absolutely not helpful. I need to implement a migration between two TYPO3 databases. This includes tables like fe_users
. The pulling system has a connection to the foreign fe_users
, but uses its own TCA to determine the DefaultRestrictionContainer
values - which is wrong: it must ignore the restrictions if the table is not from its own system (even if it has the same name), not just by checking the local TCA.
setRestrictionContainer
to just null
is not possible, it requires a valid container.
So, the only way to get rid the default restrictions seems to be to create an empty pseudo-container - this is highly inconvinient.
There must be a way (a constructor argument, a flag, a method, something) to remove/non-inject restrictions from a fresh Query.
Updated by S P over 6 years ago
Just found $query->getRestrictions()->removeAll()
- this solves this. It is strange however to find this method behind a getter. All restrictions are set directly on the query (directly by ->where
or by passing a container), but to remove them one has to fetch the container first. There should probably a wrapper method $query->removeRestrictions()
alongside resetRestrictions()