Een *.sql file op syntax checken
Voor mijn projecten maak ik geregeld een SQL-file voor de aanpassingen aan de database, maar het zou tof zijn dat ik tijdens het deployment of via een test-script direct kan zien of alles goed is, qua syntax.
Iemand een idee?
Wat eigenlijk nog veel belangrijker is is dat je altijd een soort van exit strategie hebt. Immers, wanneer een update om wat voor reden dan ook niet slaagt zou het kunnen zijn dat je ineens in de blubber vaststaat, met geen weg terug.
Dan is de vraag, hoe komt deze SQL-file tot stand, en waarom is er reden om aan te nemen dat dit niet altijd goed gaat?
Als je dit achterliggende probleem wegneemt, door bijvoorbeeld dit soort wijzigingen te testen op een (qua content en structuur) up-to-date ontwikkeldatabase -wat mij sowieso verstandig lijkt- dan kom je zelden tot nooit in de problemen lijkt mij?
Daarnaast is ook de vraag, hoe vaak verandert de structuur (aangenomen dat het om structuur gaat), kan dit tijdens een onderhoudscycle, is het mogelijk om backups te maken et cetera?
En als je heel vaak structurele wijzigingen hebt, dan klinkt het gewoon alsof er iets moet veranderen aan het ontwerp zelf.
Overigens, de makkelijkste manier om na te gaan of de syntax klopt lijkt mij nog steeds het simpelweg uitvoeren van de SQL.
Het kán fout gaan als er een foutje in de migratie-SQLfile staat (elke versie verandert er wel iets aan de database, dat zit verder wel goed), maar het is zonde als ik weer de database moet leeggooien en opnieuw moet inladen etc. Dus daarom was ik benieuwd of er iets bestaat wat een reeks queries (in bijv. een sql-file) controleert. Desnoods een functie in MySQL / MariaDB ofzo.
Gewijzigd op 23/04/2019 01:21:00 door - Ariën -
Quote:
Uiteraard test ik het op een test-locatie. Maar een controle vooraf of de syntax goed is, lijkt me geen overbodige luxe tijdens een deployment met de upgrade-scripts.
Maar dat doe je toch op de testomgeving? Deze moet representatief zijn voor wat op productie actief is. Wat ben je anders aan het testen? Dus als je voor zo'n upgrade dan je database/content/whatever van productie terughaalt en de upgrade uitvoert en dat werkt, dan zou het op productie ook moeten werken. Tenzij jouw testomgeving niet representatief is voor je productieomgeving, en dan heb je een heel ander probleem.
Quote:
Het kán fout gaan als er een foutje in de migratie-SQLfile staat (elke versie verandert er wel iets aan de database, dat zit verder wel goed), maar het is zonde als ik weer de database moet leeggooien en opnieuw moet inladen etc.
Is wat je zegt niet tegenstrijdig? Volgens mij sluit je dit op de bovenstaande wijze uit, of je voorkomt in ieder geval op die manier dat je stront hebt op productie.
Neemt niet weg dat je dus meer maatregelen zou moeten treffen, zoals (in die volgorde):
- het sluiten van de site voor publiek tijdens onderhoud zodat er geen data meer kan worden gewijzigd
- het maken van een backup
- het doorvoeren van de wijziging(en)
- en natuurlijk ff testen of alles na afloop nog naar behoren werkt
Dit lijkt mij de enige manier om te waarborgen dat er niets mis kan gaan en als dat onverhoopt toch gebeurt dat je:
- terug kunt naar de werkende situatie door het terugzetten van de backup
- onderwijl kunt uitzoeken waarop de upgrade niet lukte en dan te besluiten om dat dan te repareren of de upgrade voorlopig maar uit te stellen
Daarbij is het ook verstandig om eens te testen of het terugzetten van de backup wel werkt anders is dat ook een wassen neus.
Je moet het zo zien: mits de omstandigheden/randvariabelen/toestand van de data op twee omgevingen hetzelfde zijn, dan zou het effect van eenzelfde wijziging in beide omgevingen hetzelfde resultaat moeten hebben. Dat is het fijne van (programma)code, die besluit niet zelf om ineens verschillende dingen te doen in een "identieke" setting.
Het kan ook enorm helpen om lijn aan te brengen in zo'n upgrade in de vorm van een procedure. Zorg dat de handelingen die je uitvoert altijd hetzelfde zijn en een voorschrift volgen. Dit helpt verder bij het verkleinen van de kans dat een upgrade mislukt. En als het dat toch misgaat, is dat waarschijnlijk 9 van de 10 keer te herleiden tot het niet volgen van de procedure en ligt dat niet aan de upgrade zelf.
Gewijzigd op 23/04/2019 09:53:58 door Thomas van den Heuvel
Gewijzigd op 23/04/2019 10:02:38 door - Ariën -
(5 minuten googlen overigens)
Gewijzigd op 23/04/2019 10:51:58 door Thomas van den Heuvel
Ik zal eens kijken, maar ik zoek toch liever wel iets wat ik geautomatiseerd kan uitvoeren.
Edit: Ik heb gekeken naar die site, die je noemde, en die heeft moeite met meerdere queries onder elkaar, terwijl ze gewoon gescheiden zijn met een punt-komma.
Gewijzigd op 23/04/2019 11:56:55 door - Ariën -
Want je wil je productiedatabase toch niet gaan breken na een deploy?
Maar goed, voor wat ik nu heb zoek ik toch echt graag een oplossing om een bestand met SQL-queries te controleren qua syntax.
Ook tijdens de ontwikkelingen wil je toch test-methodes ontwikkelen? Nietwaar?
Een framework met die mogelijkheid komt ooit eens, als ik er meer tijd voor heb.
Gewijzigd op 23/04/2019 16:18:05 door - Ariën -
https://packagist.org/?query=sql%20validate