[MySQL] Serie querys, of niets

[jsiegmund]

Omdat ik er via de search en de manual niet achter kwam maar even een nieuwe topic.
Het probleem: ik wil op een standaard MySQL server (staat niet bij mezelf dus kan aan de config niets veranderen) een aantal query's uitvoeren. Als een van die query's niet lukt moet de rest ongedaan worden gemaakt, zodat er niets veranderd in de database. Als ze allemaal goed gegaan zijn mogen de veranderingen opgeslagen worden. Ik weet het, klinkt als BEGIN en COMMIT, en zo zou het eigenlijk ook moeten zijn. Mits het niet zo is dat dat alleen werkt op transactual DB's zoals BDB en ik die dus niet kan installeren.
Zijn er meer oplossingen in MySQL om dit probleem te tackelen?

[Rotjeknor]

Misschien iets te weinig info... ben je van plan dit via php te maken, of zou dit rechtrstreeks via de commandline moeten gebeuren?

Ik neem bij deze aan dat het via php moet gebeuren omdat je over een aantal queries spreekt. Wat je kan doen is na elke query een variabele true of false maken afhankelijk van het resultaat van je query. Of is het misschien toch niet zo makkelijk? (-:

[Bosmonster]

Allereerst:

http://www.mysql.com/doc/en/COMMIT.html

Je kunt uiteraard ook iedere willekeurige taal gebruiken om met de MySQL server te connecten en zelf de controles/rollbacks uit te voeren.

[jsiegmund]

Dat stukje over COMMIT had ik zelf dus al gevonden, dat krijg ik niet aan de praat op die server. De opdrachten werken wel, maar ze doen niets. Ok die heeft uitleg nodig :): BEGIN; werkt, maar daarna een UPDATE veranderd de tabel gewoon, terwijl dat dus niet zou moeten gebeuren totdat je COMMIT invoert. En een ROLLBACK geeft een error 1196: "Warning: Some non-transactional changed tables couldn't be rolled back", COMMIT wordt natuurlijk wel goed uitgevoerd.

Extra info: systeem draait op MySQL 3.23 en het is inderdaad in combinatie met PHP (versie 4.2.2). En Rotjeknor: zo makkelijk is het niet, want wanneer er in dit geval al wat wijzigingen zijn uitgevoerd blijven die nog gewoon (fout) in de database staan.

[Verwijderd]

gooi mysql eraf en zet er postgresql erop. Gooi php er dan ook maar af en zet er j2ee op. Tenslotte gebruik je een cmp ejb voor je transacties functies, werkt perfect!

[jsiegmund]

Als je even niet zo lui zou kunnen zijn en ff zou lezen server is niet van mij, config. changes are not done...

[kvdveer]

Je hebt innodb-tables nodig. Ik kan hiervandaan natuurlijk niet zien of je die beschikbaar hebt. Als je die niet hebt, dan heb je pech gehad.

gooi mysql eraf en zet er postgresql erop. Gooi php er dan ook maar af en zet er j2ee op. Tenslotte gebruik je een cmp ejb voor je transacties functies, werkt perfect!

Rot alsjeblieft op. Heb je niets te melden, zeg dan ook niets.

[D2k]

Hoewel kvdveer het wat bot brengt, ben ik het er 100% mee eens. peklosd, als je niets te vertellen heb mbt het onderwerp zeg dan ook niets
[/offtopic]

[CyberSnooP]

Hoewel peklosd het wat bot brengt komt het er op neer dat jouw MySQL versie standaard helemaal geen transactions ondersteund tenzij je (zoals kvdveer verteld) een andere tabeltype gaat gebruiken (zoals InnoDB). Verder zijn transactions bij mijn weten redelijk lastig na te bootsen. Wat misschien helpt is gewoon je tabel locken en vervolgens alle data die je update eerst in je PHP script te onthouden waardoor je de data zelf terug kunt zetten. Vereist een boel queries en programmeer werk extra helaas.

[MisterData]

CyberSnooP schreef op 01 december 2002 @ 13:41:
Hoewel peklosd het wat bot brengt komt het er op neer dat jouw MySQL versie standaard helemaal geen transactions ondersteund tenzij je (zoals kvdveer verteld) een andere tabeltype gaat gebruiken (zoals InnoDB). Verder zijn transactions bij mijn weten redelijk lastig na te bootsen. Wat misschien helpt is gewoon je tabel locken en vervolgens alle data die je update eerst in je PHP script te onthouden waardoor je de data zelf terug kunt zetten. Vereist een boel queries en programmeer werk extra helaas.

En de snelheid gaat er drastisch op achteruit.... misschien als je een TEMPORARY table gaat gebruiken?

[Glimi]

MisterData schreef op 01 december 2002 @ 15:05:
En de snelheid gaat er drastisch op achteruit.... misschien als je een TEMPORARY table gaat gebruiken?

Je select's statements gaan er inderdaad op achteruit qua snelheid, maar inserts/updates gaan juist stukken sneller door de row-level locking bij InnoDB ipv MySIAM's table locking

[Goodielover]

Ik ga er even vanuit dat je niet kan rollbacken.
Wat je kan doen is selects uitvoeren waarin je probeert om de condities om de transactie af te moeten breken eerst simuleert. Als je dan weet dat alle statements goed zouden gaan, dan doe je alle update's en delete's en inserts.

Dus: pre-condities uitvoeren, dan alle wijzigingen en vervolgens controleren.

Eventueel insert je eerst alle te wijzigen records in een temp tabel, zodat je nog herstel mogelijkheden hebt. Je bouwt dan je eigen transactie omgeving.