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
Transaktionen u. Stored Procedures verwenden
Hallo,
über die Standard API nicht, aber grundsätzlich kannst du alles machen was PHP zulässt
georg
...aber grundsätzlich kannst du alles machen was PHP zulässt
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).
Würde das Thema gerne auffrischen, gibt's da inzwischen weitere Erkenntnisse?
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.
ich habs jetzt hinbekommen, kein hexenwerk eigentlich^^
$res = $GLOBALS['TYPO3_DB']->sql_query("CALL sp_logError('".$var1."', '".$var2."')");
Für alle SP-Gegner: es gibt einen Performance-Gewinn bei uns von 800%
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."') " ) ;
Edit: die leerzeichenam schluss um das doppelte anführungszeichen sollten keine auswirkung zeigen, kann man aber entfernen. (foromat und so ...)
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.
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
@performance: ja, dachte ich schon. ist bei mir auch manchmal so, wenn es mit verschachtelten selects dann einfach nimmer geht. (man stösst da irgendwann an die grenzen der hirnwixerei, sry für den ausdruck 😉)
ich glaube aber, dass SP auch gegenüber verschachtelten selects einen performance-vorteil bringt. müsste man mal testen.
@phpmyadmin: naja, ok. händisch. ich hätte es halt gerne in der ext_tables.sql oder wenigstens in der ext_tables_static+adt.sql
dann hab ich die sp schön in der ext und wenn ich was an der sp ändere und das deploye würde das über das 'normale' db-aktualisieren im installtool entsprechend aktualisiert.
anders finde ich es nicht so prickelnd wie gesagt. einfach eine fehlerquelle mehr beim deployen, und wenn man mehrere ext mit mehreren SPs hat, dann wird das unübersichtlich.
Moin,
nach langer Zeit kram ich das Ding mal wieder raus.
Uns ist die DB nämlich grad um die Ohren geflogen, weil wir nur die Tabellen auf eine neue DB rübergezogen haben und die SPs vergessen haben. Das würde man verhindern können, wenn man die SPs auch in eine ext_tables.sql schreiben könnte. Hat da jemand schon Ansätze?
Gruß Sven
Ich möchte mich hier noch einmal einklinken. Ich möchte meine SP aus einer extbase-Extension aufrufen (Typo3 6.2)
Mit dem statement-Statement funktioniert es nicht:
$res = $query->statement("CALL sp_MyProcedure()")->execute();
...und mit dem sql_query-Statement auch nicht:
$res = $GLOBALS['TYPO3_DB']->sql_query("CALL sp_MyProcedure()");
Wie ist in der Sache der Stand der Dinge?