OK, sowas kenne ich nicht, bei mir gibt es nur das automatische Datensätze hinzufügen.und veraltete Einträge werden gelöscht
Dein Einwand ist berechtigt, aber die Ext selbst nutzt den Index nicht. Das war natürlich das erste was ich überprüft habe, bevor ich anfing nach Reset Lösungen für den auto_increment Index zu suchen. Das Ganze ist auch ausgiebig getestet, wie erwartet keine Probleme damit wenn man den Index neu aufbaut. Der Index dient also quasi nur zum separieren der Records, zu mehr nicht.oxpus hat geschrieben: ↑25.09.2021 20:57 Allerdings habe ich etwas Bauchschmerzen damit, wenn Du mit der Extension einen Primärindex neu initiieren willst, auf den sich normalerweise SQL-Anweisungen stützen, um gezielt Daten auszulesen oder zu bearbeiten.
Ich hoffe nur, Du weißt was Du tust, denn ansonsten könnte es logische Fehler in den Daten oder gar Fehlermeldungen aus der Datenbank hageln, wenn wartende SQL-Anweisungen falsche Bezüge zu einem neu aufgebauten Index verwenden.
sql_transaction('commit') gar nicht notwendig war, die Queries wurden trotzdem ausgeführt. Ich bin davon ausgegangen, das man mit sql_transaction('begin') eine Art Job-List erstellt, die man dann per sql_transaction('commit') ausführen kann. Laut Test verhält sich das jedoch anders, weshalb ich davon ausgegangen bin, das die Transactions Methode doch nicht das richtige ist.sql_transaction('commit') erfolgt? Doc hatte zwischenzeitlich den Gedanken, ob das der DB Layer von phpBB automatisch erledigt, wenn sql_transaction('begin') ausgeführt wurde. Wie siehst du das? Jein.
sql_transaction('commit') nicht notwendig, da das Schließen der Datenbankverbindung auch immer ein COMMIT auslöst und damit die Datenbank eine begonnene Transaktion ausführen lässt.COMMITbeenden, da bei einem Fehler zwischen dem logischen Ende der Transaktion und dem Schließen der Datenbankverbindung eine begonnene Transaktion eben nicht sofort ausgeführt wird.ROLLBACK der bis dahin möglicherweise erfolgreichen Transaktion auslösen könnte.DELETE, UPDATE, INSERT oder REPLACE gedacht und weniger für ein ALTER TABLE oder gar ein DROP INDEX, CREATE INDEX, ALTER INDEX.COMMIT der Transaktion wiederum sinnvoll, insbesondere, wenn ein Tabellen-Index geändert wird, um möglichst keine oder nur einzelne Folgefehler zu erhalten.
phpbb_session Tabelle als Vorbild und nutz keinen autoincrement, der sich irgendwann überschlagen könnte.session_id mit übernehmen und auch als Primar key verwenden.(non unique 0).Nö, wenn ich die Tabelle mit Datumspräfix täglich erstelle, kann ich die vom Vortag löschen,weil da keine Daten mehr einfließen können. Bedient werden nur Tabellen, die das Tagesdatum tragen.
Das war das fehlende Puzzleteil, danke.oxpus hat geschrieben: ↑26.09.2021 07:21 Wenn nach dem logischen Ende der SQL-Anweisungen einer Transaktion keine weiteren SQL-Anweisungen vor dem Schließen der Datenbankverbindung vorkommen, wäre einsql_transaction('commit')nicht notwendig, da das Schließen der Datenbankverbindung auch immer einCOMMITauslöst und damit die Datenbank eine begonnene Transaktion ausführen lässt.
Jupp, die Rollback Funktion wäre in dem Fall wirklich unerwünscht, denn der Code sollte auf jeden Fall ausgeführt werden. Damit du mich nicht missverstehst; ich hatte nicht vor den COMMIT einfach wegzulassen. Das diente nur zum testen und verstehen was bei einer Transaktion passiert. Ich muss den COMMIT auf jeden Fall senden, weil die Reset Funktion beim Event Aufruf gleich als erstes ausgeführt werden soll, wenn der AI Wert eine bestimmte Grenze überschritten hat. Und direkt danach erfolgt die normale Prozedur, bei der auch sofort wieder Änderungen an der Tabelle vorgenommen werden können/müssen.Dennoch sollte man Transaktionen immer schnellstens und damit sauber mit einemCOMMITbeenden, da bei einem Fehler zwischen dem logischen Ende der Transaktion und dem Schließen der Datenbankverbindung eine begonnene Transaktion eben nicht sofort ausgeführt wird.
Das kann auch ein simpler PHP-Fehler sein, da dieser die Datenbankverbindung nicht zwangsweise schließt und somit auch ein an dieser Stelle unerwünschtesROLLBACKder bis dahin möglicherweise erfolgreichen Transaktion auslösen könnte.
Okay, es ist also nicht sicher, dass eine Transaktion meinen Reset Code schützen würde? Denn ich benötige dabei sowohl ein UPDATE als auch ein ALTER TABLE.Allerdings bin ich mir nicht sicher, ob eine Transaktion auch davor schützt, wenn damit ein neu aufzubauender Tabellen-Index ausgeführt werden soll. Schließlich ist eine Transaktion eher für die "üblichen" SQL-Abweisungen wieDELETE,UPDATE,INSERToderREPLACEgedacht und weniger für einALTER TABLEoder gar einDROP INDEX,CREATE INDEX,ALTER INDEX.
Wobei sich alle beliebigen SQL-Anweisungen in einer Transaktion zusammenfassen lassen. Und wenn diese logisch korrekt aufeinander aufbauen, sehe ich auch kein Problem, am Ende der logischen Transaktion auch einen Index neu zu setzen.
Wie gesagt, dieser Index selbst wird von der Ext gar nicht verwendet. Wie sich das aber seitens der DBMS selbst verhält, weiss ich stand jetzt nicht. Meine Tests gingen nur in die Richtung festzustellen, ob die Ext ein Problem mit geändertem Index hat. Das fand jedoch nur in einem lokalen TB statt, wo es logischerweise ausser mir niemand gibt der parallele/konkurrierende SQL Queries initiieren würde.Dennoch:
Während der Index einer Tabelle in einer Transaktion bearbeitet wird, nimmt die Datenbank ja auch immer neue Befehle entgegen.
Aber was passiert dabei, wenn die Transaktion beendet ist und die geänderten Primärschlüssel nicht mehr zu den nachfolgenden SQL-Anweisungen passen?
Innerhalb einer Transaktion kann man das noch kontrollieren, aber die wartenden SQL-Anweisungen kennen den neuen Index nicht, wenn dieser in einer Transaktion geändert wurde.
Das geht schon alleine deswegen nicht, weil der Endbenutzer zwischen zwei Zeit-Modellen auswählen kann: Heute und Zeitraum. Und bei letzterem kann er auch frei definieren, wie gross dieser sein soll. Präzise in Stunden, Minuten und Sekunden.69bruno hat geschrieben: ↑26.09.2021 10:27 Stünde denn einer Änderung der Tabellenstruktur etwas entgegen, dass es keine "gelöschten" DS mehr gibt und täglich eine neue Tabelle angelegt wird ? Veraltete Tabellen können ja komplett gelöscht werden. Dann würde es doch gar kein Problem mit dem autoincrement geben.....
Das klingt sehr interessant! Wenn es einen Weg geben würde den auto_increment Wert ganz loszuwerden, würde ich diesen sofort gehen.
