Hej,
1.
Mit dem Befehl $query->getQuerySettings()->setRespectEnableFields(false) kann ich gemäss Doku ja auch Einträge anzeigen lassen, die auf hidden/deleted=1 gesetzt wurden.
Wenn ich aber darin eine Relation zu Kind-Objekten habe, scheint ihn das nicht zu interessieren.
Gibt es hier eine andere Möglichkeit die gelöschten Kind-Objekte auch anzeigen zu lassen?
2.
Beim debbugen von 1. habe ich gesehen, dass er für die Haupttabelle ein SQL macht und die Childs für die WHERE Überprüfung mit einem LEFT JOIN dran hängt.
Um die Daten zu holen wird dann aber beim Auflisten jedes Child separat mit "WHERE uid IN (105)" geholt! Und das mehrfach!
Habe ich im Aufruf etwas falsch gemacht oder ist das normal so?
Mein Query Aufruf sieht so aus:
// build query
$query = $this->createQuery();
$constraints = array();
// find deleted entries !
$query->getQuerySettings()->setRespectEnableFields(false);
$constraints[] = $query->like('contact.name','TYPO3%');
// ...usw...
// merge Conditions AND
if(count($constraints)>0) {
$query->matching($query->logicalAnd($constraints));
}
// execute
$result = $query->execute();
return $result;
Danke für jeden Tipp.
Zu 1:
Das Problem ist bekannt und wird auf Forge heftig diskutiert. Ich hab das jetzt aber nicht weiter verfolgt, aber schaut so aus als wenn das erst in der 6.0er Version verfügbar ist:
http://forge.typo3.org/issues/8483
Zu 2:
Mir ist das auch aufgefallen. Ich glaub das war mal anders. Version 1.2?!?! Ich finde diese neue Variante allerdings nicht verkehrt. Eine Abfrage auf Basis der UID geht immer extremst schnell während find_in_set den Index einer Tabelle nicht verwenden kann. In meinen Tests war eine aneinander gekettete OR-Abfrage auf die UID 10mal schenller als ein kommaseparierte Liste in find_in_set.
Stefan
Hey Stefan,
Vielen Dank.
Wenns in Version 6.0 kommt ist super, kann ich noch warten.
Das mit der Performance ist interessant. Wusste nicht, dass FIND_IN_SET so langsam ist. Allerdings sind die Datensätze n:1 verlinkt, also kein FIND_IN_SET nötig sondern einfach mit LEFT JOIN anhängbar. Und im ersten SQL wird das ja auch schon verknüpft, damit die WHERE Clause auf den Childs überhaupt durchgeführt werden kann! Zusätzlich wird dann in der Auflistung für gleiche Verknüpfungen (also z.Bsp. Child mit uid 4) jedes Mal wieder das Object per SQL geholt und gemappt!
Weiss jetzt nicht wie das Doctrine oder andere machen würden...