statement, ORDER BY und widget:paginate [Gelöst]

  • 0 x
    28 Beiträge
    0 Hilfreiche Beiträge
    14. 06. 2013, 11:48

    Hallo zusammen,

    Ich sitze gerade an einem Projekt in T3 4.5, also Extbase 1.3.

    Ich habe Filialen, über die es monatliche Berichte gibt.
    In einer Tabelle werden nun alle Filialen mit den Zahlen aus den Berichten angezeigt.
    Soweit, so gut. Jetzt soll aber sortiert werden...

    In SQL würde ich das einfach so machen (SQL ist stark vereinfacht, da noch Filter und Berechtigungen hinzukommen. Je nachdem umspannt der SELECT 5 Tabellen):

    1. SELECT
    2. f.*,
    3. SUM(m.gesamt) AS gesamt
    4. FROM
    5. tx_xxx_domain_model_filiale AS f,
    6. tx_xxx_domain_model_monatsbericht AS m
    7. WHERE
    8. m.filiale = f.uid
    9. GROUP BY
    10. f.uid
    11. ORDER BY
    12. gesamt

    Klappt mit $query->statement auch.
    Da ich aber f:widget.paginate benutze, brauch ich als Rückgabewert Tx_Extbase_Persistence_QueryResultInterface, kein Array.
    Könnte ich ja dann so machen:
    1. $resultArray = $querySt->execute();
    2. $uids = array();
    3. foreach ($resultArray as $value)
    4. {
    5. array_push($uids, $value['uid']);
    6. }
    7. $query = $this->createQuery();
    8. $query->matching($query->in('uid', $uids));
    9. return $query->execute();

    So fliegt mir aber die Sortierung raus und $query->setOrderings(array('uid' => Tx_Extbase_Persistence_QueryInterface::ORDER_DESCENDING)); geht ja nicht.

    Kann ich irgendwie die Sortierung ausschalten oder gibt es in Extbase eine andere Möglichkeit, die zu bewerkstelligen?

    Beste Grüße
    Jan


  • 1
  • kitsunet kitsunet
    Flash Gordon
    0 x
    2559 Beiträge
    27 Hilfreiche Beiträge
    14. 06. 2013, 13:19

    Das bringt dir ja alles nichts, das Widget braucht deshalb ein QueryResultInterface weil da die Daten noch nicht drinstehen sondern nur die generierte Query. Die wird dann vom Widget mit LIMIT modifiziert um die Pagination zu machen. Mal abgesehen davon, dass das was du vorhast extrem langsam ist, wird es nicht funktionieren. Außerdem verstehe ich gar nicht welche uids Du da nehmen willst? Z.b. von filiale dann bekommst du am Ende ja nur deine Filialobjekte raus aber nicht deine aggregierten Daten, also das "gesamt".

    Du musst Dir für diesen Fall die Pagination schon von Hand bauen, kann man ja vom Paginate VH ableiten.

    config.baseURL = http://www.kitsunet.com/
    TYPO3 Flow und Neos Community Contact
    Release Manager TYPO3 Neos 1.1
    Ich habe Probleme mit den PMs hier, also schreibt mir bitte eine Mail oder über Twitter!

  • 0 x
    28 Beiträge
    0 Hilfreiche Beiträge
    14. 06. 2013, 13:40

    >> Außerdem verstehe ich gar nicht welche uids Du da nehmen willst? Z.b. von filiale dann bekommst du am Ende ja nur deine Filialobjekte raus aber nicht deine aggregierten Daten, also das "gesamt".

    An die Daten komme ich über einen Getter im Filial-Objekt dran, der mir im Model diese und andere Zahlen zusammenbaut, daher kein Problem.

    Das Ergebnis der zweiten Query kann ich für das Widget ja benutzen, es geht daher nur um die Sortierung.
    Allerdings ist die Performance ein Problem, da hast du auf jeden Fall recht.

    Ich werd das Model nochmal überarbeiten und die benötigten Werte wie gesamt ins Filial-Objekt packen, ist ein wenig redundant, aber das wird mir einiges erleichtern - weniger JOINs, kein eigens Widget, hoffentlich Performance.

    Danke
    Jan

  • froemken froemken
    Jedi-Ratsmitglied
    0 x
    811 Beiträge
    1 Hilfreiche Beiträge
    22. 07. 2013, 22:28

    Ähnliches Problem hatte ich auch mal. Hab wie kitsunet schon angekündigt ein eigenes paginate-Widget gebaut. Die Queries werden mit statement() gebaut. Die Query enthält statt der Felder ###SELECT### und für das Limit ###LIMIT###. Das Ergebnis nach einem execute() ist nun auch ein QueryResultInterface, dass in dem eigenen paginator verwendet werden kann.
    Innerhalb des paginators habe ich dann eine Methode, die das ###SELECT### durch COUNT(*) ersetzt und das ###LIMIT### durch einen leeren String. Dadurch können dann die zu generierenden Seiten berechnet werden. Dann eine weitere Methode, um###SELECT### durch die Spalten zu ersetzen und ###LIMIT### für den offset und die Anzahl der auf einer Seite anzuzeigenden Einträge.
    War eine scheiß Arbeit, aber damit habe ich die Daten nun in der Reihenfolge, wie ich sie haben will.

    Stefan

  • 1