SearchBase: Support von Gruppen

[digedag]

Es kommt immer wieder der Wunsch auf, SQL-Queries mit OR zu erstellen. 😉 Die Antwort ist dann immer der Verweis auf SEARCH_FIELD_CUSTOM. Eine saubere Lösung wäre natürlich besser. Die Struktur der Gruppierung könnte so aussehen:

$fields['SEARCH_FIELD_GROUP'] = [
  'OPERATOR' => 'OR', // oder AND, default sollte OR sein
  'MYTABLE.UID' => [OP_EQ_INT => 22],
  'MYTABLE.UID' => [OP_EQ_INT => 23],
  'SEARCH_FIELD_GROUP' => [
  ]
]

Das Beispiel ist natürlich sinnlos und soll nur die notwendige Struktur beschreiben. Damit wären auch Verschachtelungen möglich und die Notation kann auch einfach per Typoscript gesetzt werden.

Gibt es Anmerkungen?

[digedag]

Innerhalb einer Gruppe sollte man unbedingt mehrere Subgruppen angeben können. Somit muss die Struktur erweitert werden. Per TS würde es so aussehen:

fields.SEARCH_FIELD_GROUP {
  OPERATOR = OR
  10.MYTABLE.UID.OP_EG_INT = 123
  15.SEARCH_FIELD_GROUP {}
  20.SEARCH_FIELD_GROUP {}
}

Die Einschränkung, daß innerhalb einer Gruppe nur ein Operator (OR|AND) gilt, ist meiner Ansicht nach akzeptabel.

[rengaw83]

👍 Super Idee!

Um es dann noch einmal einfacher zu machen, vielleicht den Operator weg lassen und die Int-Keys nur bei den Groups:

fields {
    10.SEARCH_GROUP_OR {
        10.SEARCH_GROUP_AND {
            TABLE.special.OP_EQ_INT = 1
            TABLE.specialprice.OP_GT_INT = 20
        }
        20.SEARCH_GROUP_AND {
            TABLE.special.OP_EQ_INT = 0
            TABLE.price.OP_GT_INT = 20
        }
    }
    20.SEARCH_GROUP_OR {
        ...
    }
}

SELECT * FROM products
WHERE (
    (
        TABLE.special = 1 AND TABLE.specialprice > 20
    ) OR (
        TABLE.special = 0 AND TABLE.price > 20
    ) 
) AND (
    ...
)

Für solch eine Abfrage ist das nutzen von Keys wichtig, damit die beiden ANDs nicht in einem AND landen. Dann muss das aber Konzequent für alle SEARCH_GROUPs durchgezogen werden.
Heißt, wenn der Key ein Numeric ist, muss nach SEARCH_GROUP geschaut werden, ist es ein String enthält es direkt eine Tabellennotation.

Den 'mischmasch' aus deinem Beispiel finde ich verwirrend und technisch etwas komplexer lösbar. Mal schreib ich mit mal ohne die Keys.

Sowas würde dann nicht gehen, auch wenn es mir logischer erscheint:

fields {
    SEARCH_GROUP_OR {
        SEARCH_GROUP_AND {
            TABLE.special.OP_EQ_INT = 0
            TABLE.price.OP_GT_INT = 20
        }
    }
}

[digedag]

Den Operator in die Konstante zu übernehme finde ich eine super Idee! Damit kann man auf den Mischmasch zwischen numerischen und String-Key eigentlich komplett verzichten. Das macht es vor allem im PHP Code dann einfacher.

Auf der obersten Ebene würde ich aber alles lassen wie bisher. Dafür würde ich innerhalb der Gruppen, dann aber konsequent bei numerischen Keys bleiben:

fields {
    # Auf der obersten Ebene nur genau einmal OR (und einmal AND) möglich.
    SEARCH_GROUP_OR {
        10.SEARCH_GROUP_AND {
            10.TABLE.special.OP_EQ_INT = 1
            20.TABLE.specialprice.OP_GT_INT = 20
        }
        20.SEARCH_GROUP_AND {
            10.TABLE.special.OP_EQ_INT = 0
            20.TABLE.price.OP_GT_INT = 20
        }
        30.TABLE.sale.OP_EQ_INT = 1 
    }

    SEARCH_GROUP_AND {
        ...
    }
}

Die Umsetzung in PHP wäre dann so:

$fields[SEARCH_GROUP_OR] = [
  [
    SEARCH_GROUP_AND => [
      ['TABLE.special' => [OP_EQ_INT => 1]],
      ['TABLE.specialprice' => [OP_GT_INT => 20]],
    ]
  ],
  [
    SEARCH_GROUP_AND => [
      ['TABLE.special' => [OP_EQ_INT => 0]],
      ['TABLE.price' => [OP_GT_INT => 10]]
    ]
  ],
  [
    'TABLE.sale' => [OP_EQ_INT => 1],
  ]
]

Arrays mit mehreren Keys wären dann immer Gruppierungen. Wenn nur ein Key vorhanden ist, wäre es eine Bedingung.