Bug #83296

Doctrine respects wrong storage PIDs for sys_category

Added by Stefan Froemken over 3 years ago. Updated 2 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2017-12-12
Due date:
% Done:

0%

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

Description

Hello,

our events2 extensions does not show any records in frontend after upgrading to current TYPO3 8.

We found out, that the executed SQL includes an additional WHERE-Statement to "sys_category.pid IN (3)". But we don't have any sys_category records in this storage folder. The storage folder with UID 3 includes event records only. For our categories we have created an additional storage folder with UID 12.

It works if we append UID 12 to the list of plugin.tx_events2.persistence.storagePid.

We are using the CategoryRepository from extbase which has an initializeObject method where respectStoragePage was set to false. In Typo3DbQueryParser->addTypo3Constraints the QuerySettings of my Repository was used for ALL related repositories incl. sys_category. This is a new behaviour.

Is there still a possibility to respect individual repository QuerySettings?

Stefan


Related issues

Related to TYPO3 Core - Bug #89295: Typo3QuerySettings set as DefaultQuerySettings in a Repositories initializeObject Method are not honoredResolved2019-09-27

Actions
#1

Updated by Riccardo De Contardi 3 months ago

Is this issue still valid? I have seen that the latest version of EXT:events2 supports TYPO3 9+

#2

Updated by Christian Kuhn 2 months ago

  • Related to Bug #89295: Typo3QuerySettings set as DefaultQuerySettings in a Repositories initializeObject Method are not honored added
#3

Updated by Christian Kuhn 2 months ago

  • Status changed from New to Closed

Hey Stefan.

I had a look at the query settings and stumbled upon your issue.

It looks as if you somehow solved it meanwhile, so I'll close the issue for now.

Two things though:
  • Extending your repository from the generic repositories can be problematic. In general I'm not a huge fan of the extbase generic fe/be user repos (and models) and the category repo. They force things to you, you may not want and maybe even don't realize at first. I'd suggest to simply not extend your category repo from the extbase generic one to give you more freedom.
  • Fiddling with defaultQuerySettings can be tricky. They have the side effect that other query settings usually set by data mapper or config are overridden / reset. This can not be solved easily and is also under-documented. I'll add more information in this regard to issue #89295, which I just related. I guess we'll have to keep the unfortunate defaultQuerySettings situation as is, but we should at least add more information to the code to hint people about possible side effects.
#4

Updated by Stefan Froemken 2 months ago

Yes, I have found a solution. I have switched from Extbase Query to Doctrine QueryBuilder.
You will find my solution in DatabaseService.php here: https://github.com/jweiland-net/events2/blob/master/Classes/Service/DatabaseService.php

See getConstraintForPid which only set pid for day and event table but not sys_category, and getConstraintForCategories.

So closing this issue is absolutely OK for me.

#5

Updated by Christian Kuhn 2 months ago

I see. Yeah, directly using core db API instead of extbase query building when appropriate drops some layers of complexity (and is much quicker). We'll switch a couple of core places to this, too ;)

Also available in: Atom PDF