[TYPO3-mvc] Translation handling a bit too strict?

[Andreas Kiessling]

Hi,

in a current project, i have added an IRRE relation from tt_content to 
custom records.
This resulted in some trouble outputting the right records with extbase...

I stumbled upon the problem when i faced this irre bug: 
http://bugs.typo3.org/view.php?id=13250 which is pending in core list, 
but should be treated independently of this.

Additional note to this bug: for my project, i have now removed the 
ability to localize the irre records as it wasn't "really needed" and 
would have created more confusion than it could have helped the editor 
to create the content. -> "Problem solved for me in this case"

Error description:
In the repository, i have a function which returns the records that are 
attached to the tt_content record.

public function findIrreSubRecords($cObjUid){
	$query = $this->createQuery();
	$query->setOrderings(array('tt_content_sorting' => 
Tx_Extbase_Persistence_QueryInterface::ORDER_ASCENDING));
	$query
		->getQuerySettings()
		->setRespectStoragePage(FALSE)
		->setRespectSysLanguage(FALSE);
	$query->matching($query->equals('tt_content_uid', intval($cObjUid)));
	return $query->execute();
}

$cObjUid is the uid of the (probably localized) tt_content element. The 
irre records store the uid of the (localized) tt_content record, so 
$cObjUid is then either set to _LOCALIZED_UID or uid from the controll 
-> don't need a translation handling for the records here. (of course, 
no settings for l10n_mode can be used here either)

This works fine, as long as all attached records have the right 
sys_language_uid set (-> greater than 0 when in a localized tt_content 
element), because when doLanguageAndWorkspaceOverlay in the 
Typo3DbBackend is called, id does not take the query setting into 
account and tries to fetch an overlay record. If the language of the 
record is set to 0 or -1. --> record is removed when $languageMode is 
set to strict, which i usually / always do. I have never had a project 
where i needed or wanted another setting, but in this case and this 
combination of settings, this imho return the wrong records.

So: bug? intended behaviour?


Regards,
Andreas