Door
Veur Heur
op 12-03-2026 11:52
gewijzigd op 12-03-2026 11:54
827 views
Ik heb een aantal ical bestanden die ik inlees. Voordat ik dat doe, leeg ik mijn tabel. Afgelopen week gebeurde het echter dat een van de icals niet beschikbaar was, waardoor mijn script stopte en ik met een lege tabel zat. Dat kan beter. Ik dacht de volgende oplossing te hebben, echter wanneer ik een fout forceer door de url van een ical te wijzigen naar iets dat niet bestaat, is alleen de data van 1 ical beschikbaar:
$mysqli=mysqli_connect(..);
$mysqli->begin_transaction();
//legen met delete omdat truncate niet kan worden ge-rollback-t
$mysqli->query('DELETE FROM calendar;');
$mysqli->query('ALTER TABLE calendar AUTO_INCREMENT=1;');
try {
foreach($icals as $ical) {
//hier uch insert statements
}
//hier nog enkele opschoon acties (lees DELETE queries)
$mysqli->commit();
}
catch(Exception $e) {
$mysqli->rollback();
echo $e->getMessage();
}
Werkt op zich goed. In je voorbeeld gooit mysqli standaard geen Exception bij een fout.
Je kan boven je try dit toevoegen zodat database fouten ook in je catch() terecht komen.
Samenvatting van die link: "voor een ALTER TABLE wordt eerst een COMMIT gedaan"
En eerlijk gezegd zie ik eerder bezwaren dan voordelen aan het resetten van auto-increment.
Ik heb het getest en je hebt gelijk. Aangezien deze tabel geheel automatisch wordt gevuld, kan ik zonder de auto increment, dus ik denk dat ik die verwijder. Dit lijkt me althans de makkelijkste oplossing. Een andere zou zijn een tijdelijk tabel en vervolgens drop/rename..?
Het is al weer even geleden, maar door de nieuwe layout weer onder mijn aandacht gekomen :-)
Ik vind dat je onder normale bedrijfsomstandigheden niet aan de structuur van je database moet hoeven komen.
ALTER TABLE, DROP TABLE en CREATE TABLE zouden niet nodig moeten zijn.
-- en voor veiligheid zou de user waarmee de website connect met de database niet eens die rechten moeten hebben.
Voor het createn van een temporary table is nog wat te zeggen, maar dan zou daarna die inhoud doorgeschoven moeten worden naar de bestaande tabel.
Ook het aanpassen van een auto-increment is niet nodig: als je vandaag verwijst naar afspraak met ID = 123, moet dat niet morgen een heel andere afspraak kunnen zijn. En als je dat ID niet gebruikt, dan hoef je hem niet te hebben.
Of als je hem intern gebruikt (en niet in een link of url) dan doet het er ook niet toe of je bij 100 entry's in je tabel de ID kolom van 1 tot 100 hebt lopen of van 132501 tot 132600. Dat ID heeft geen betekenis voor de gebruiker.
-- en ik denk dat ook drop en rename een automatische commit gaan veroorzaken. Of je moet je script zo bouwen dat pas bij jouw "commit" het renamen van van de tabellen plaatsvindt.
