Examples: query, "exact match", wildcard*, wild?ard, wild*rd
Fuzzy search: cake~ (finds cakes, bake)
Term boost: "red velvet"^4, chocolate^2
Field grouping: tags:(+work -"fun-stuff")
Escaping: Escape characters +-&|!(){}[]^"~*?:\ with \, e.g. \+
Range search: properties.timestamp:[1587729413488 TO *] (inclusive), properties.title:{A TO Z}(excluding A and Z)
Combinations: chocolate AND vanilla, chocolate OR vanilla, (chocolate OR vanilla) NOT "vanilla pudding"
Field search: properties.title:"The Title" AND text
Beantwortet
Transaktionssicherheit bei Ausführungsregeln?

Angenommen wir haben einen Schritt mit 2 PHP-Ausführungsfunktionen, beide machen Inserts oder Updates.

  1. Szenario JobRouterDB:
    Wenn man via getJobDB Inserts und Updates macht und am Ende der zweiten Ausführungsregel JobRouterExcepted dann werden alle Änderungen der Regel(!), also beiden PHP-Funktionen, rollbacked. Dies halten wir für korrekt.

  2. Szenario getDBConnection
    Wenn man den gleichen Test macht mit getDBConnection zu einer anderen MSSQL-Datenbank dann rollt er keine einzige der Änderungen zurück. Nicht mal die aus der gleichen PHP-Funktion.

Siehe das Beispiel aus dem Feld "Sonstige Informationen". Werden diese beiden Inserts ausgeführt und danach direkt excepted dann wird bei getJobDB alles rollbacked, bei "externer" Datenbank nichts davon.

Ist das so korrekt?

Code:

			$db = $this->getDBConnection('TestDB');
    	$sql = 'INSERT INTO TEST (field_one) VALUES (?)';
    	$this->jrSQLExecute($sql, ['xyz'], $db);
    	
    	$sql = 'INSERT INTO TEST (field_two) VALUES (?)';
    	$this->jrSQLExecute($sql, ['abc'], $db);
    	
    	throw new JobRouterException('Die here');
  
  
Gepostet vor 3 Jahren
Bearbeitet vor 3 Jahren
Stefan Köngeter
309 × 7 Administrator
Stimmen Neuste

Antworten


Aufgrund der Datenbakclients müssen Transaktionen auf externen Datenbanken selbst organisiert werden, also Regeln im Regelablauf speziell mit BEGIN TRANSACTION, COMMIT und ROLLBACK angelegt werden.

Problem: Wenn man in einem Schritt mehrere Regeln hat und die Regel mit der Transaktion auf die externe DB erfolgreich durchläuft (und man die Daten committed), aber eine der nachfolgenden Regeln Fehler verursacht, dann wird der JobRouter-Schritt zurückgerollt, die schon committete Transaktion auf der externen DB aber nicht. Um diese Gefahr zu reduzieren ist es empfohlen, die Ausführungsregel in einen einzelnen Entscheidungsschritt auszulagern oder zumindest ganz ans Ende der Regelkette zu verschieben, so dass der COMMIT auf der externen DB das letzte ist, was ausgeführt wird.

  
  
wiki
Gepostet vor 3 Jahren
Stefan Köngeter
309 × 7 Administrator
5K Ansichten
1 Antwort
vor 3 Jahren
vor 3 Jahren
Stichwörter