Bug #83296
closed
Doctrine respects wrong storage PIDs for sys_category
Added by Stefan Froemken almost 7 years ago.
Updated over 3 years ago.
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
Is this issue still valid? I have seen that the latest version of EXT:events2 supports TYPO3 9+
- Related to Bug #89295: Typo3QuerySettings set as DefaultQuerySettings in a Repositories initializeObject Method are not honored added
- 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.
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
Updated by 
Updated by 
Updated by