Hallo,
ich hab mal eine ganz grundsätzliche Frage.
Ist es in eigen entwickelten Extensions möglich Transaktionen und Stored Procedures einzusetzen, z.B. über den Einsatz der PDO.
Würde sich sowas in irgendeiner Form implementieren lassen?
cooper
Hallo,
ich hab mal eine ganz grundsätzliche Frage.
Ist es in eigen entwickelten Extensions möglich Transaktionen und Stored Procedures einzusetzen, z.B. über den Einsatz der PDO.
Würde sich sowas in irgendeiner Form implementieren lassen?
cooper
ja, das sag ich auch immer, dass erst mal alles möglich ist. Dagegen steht dann immer die Frage des Aufwandes. ;)
Mir war erst mal wichtig zu erfahren, ob es standardmäßig evtl. ein simpler Weg hinführt, den ich nur noch nicht kenne.
V 5.x lieferts dann später von Haus aus.
Danke für die Info.
cooper
Ich hab nun noch mal ne Menge zum Thema rumexperimentiert und so richtig noch keinen brauchbaren Lösungsansatz.
Wenn ich die Procedures über das typo-DB-Objekt aufrufen wollte, müsste ich der mysql_(p)connect noch ein zusätzliches Attribut (client_flag) mitliefern, damit mir der Call auch Resultate zurückliefert.
Wenn ich den client_flag mal testweise in der t3lib_DB.sql_pconnect setze, funktioniert der Call sogar, allerdings werden mir jetzt aus der class.t3lib_db.php diverse warnings ausgeworfen.
Ich denke also, ich brauche eine zweite DB-connection, zumal ich meine, dass man über die Standard mysql-Funktionen sowieso nur einen Call absetzten kann und für einen zweite Abfrage die connection unterbrechen müßte.
Lässt sich so etwas in der Form lösen, dass man in seiner pi eine Instanz der t3lib_db erzeugt und die sql_pconnect entsprechend überschreibt, so dass das client_flag gesetzt wird?
Wie könnte sowas aussehen, oder vielleicht gibts noch eine ganz andere Idee.
Google gibt mir inzwischen irgendwie nix mehr her.
cooper
ich wäre auch interessiert an todos.
google gibt da ja gar nix her zum thema typo3 + stored procedures.
das fängt schon damit an, dass man die procedures 'händisch' importieren muss (weder ext_tabls.sql noch ext_tables_static+adt.sql lassen das zu).
To err is human; to really screw things up requires the root password.
https://www.Riccabona.IT/
https://T3BOARD.TYPO3.org/
Von meiner Seite aus leider gar nix.
Ich hab aber auch nimmer gesucht.
Das meiste konnte ich jetzt ohne STP umsetzen, mit ellenlangen verschachtelten selects.
Schön is anders, aber naja, es funktioniert.
Falls aber was kommt bin ich auch nach wie vor interessiert, ich hab ein paar megaselects, die würden rein performancetechnisch vermutlich davon profitieren.
To err is human; to really screw things up requires the root password.
https://www.Riccabona.IT/
https://T3BOARD.TYPO3.org/
WOW, 800%!
kann man über das query was erfahren das eine einschätzung möglich macht?
datenmenge, anzahl tables ...
dass sp performancemässig besser sind, war mir klar, aber 800% ist hammer.
da hat der foromat wohl was falsch formatiert ...
war es das hier?
$res = $GLOBALS['TYPO3_DB']->sql_query("CALL sp_logError('".$var1."', '".$var2."') " ) ;
wie hast du das problem gelöst die SP in die DB zu kriegen?
über ext_tables.sql bzw. ext_static....sql ist mir das leider nicht gelungen.
"händisch" find ich aber auch nicht grad prickelnd, das ist imho eine zusätzliche fehlerquelle.
To err is human; to really screw things up requires the root password.
https://www.Riccabona.IT/
https://T3BOARD.TYPO3.org/
Wieso kann ich meinen Beitrag nicht editieren?
Ja genau, Dein Statement ist richtig. Ich denke unsere Performance-Gewinn kommt daher, dass wir sonst mehrmals an die Datenbank gehen (prüfe, ob der eintrag da ist, wenn ja, nimm die id, wenn nein, füge ein und nimm die id). Fetzt schon ;)
Ich hab die Sp einfach über phpMyAdmin eingefügt. Hab zwar auch konsolenzugriff, aber wenns damit auch geht...
Beste Grüße