[SVN] version control & database

Pagina: 1
Acties:

  • maartenvdv737
  • Registratie: Augustus 2000
  • Laatst online: 16-05 20:36
ik heb een admin gemaakt voor subversion, waarmee de beheerders de nieuwe versie online kunnen zetten en ook snel weer terug naar de vorige versie kunnen mocht er iets toch niet goed zijn.

Het probleem dat ik nu heb is dat de database niet meegesynchroniseerd wordt. Deze kan echter ook tussen versies verschillen.

Ik ben op zoek naar een idee, of kant en klaar oplossing, om via de command line (en dus straks via php) databases te updaten en of de vorige versie terug te zetten, zonder een volledige backup te maken (de database is 20gb). Daar komt bij dat de data op de online versie telkens wijzigd, dus een backup terugzetten zou veel verlies betekenen.

Ik heb rondgekeken, maar de meeste tools zijn grafische tools en hebben geen version control eigenschappen

[ Voor 9% gewijzigd door maartenvdv737 op 17-01-2005 16:47 ]

Ik blijf er iig vrij nuchter onder....


  • bartvb
  • Registratie: Oktober 1999
  • Laatst online: 05-01 14:41
Dat lijkt me nogal onmogelijk. Of ja, niet onmogelijk, vooral onwenselijk.

Als je database schema in SVN zit dan kan je kijken wat het verschil is tussen versie 1 en versie 2 en aan de hand daarvan de database aanpassen met ALTER TABLE (als je MySQL gebruikt, niet alle databases willen online helemaal omgegooid worden). Hetzelfde kan je doen als je een versie terug gaat. Als er tussen versie 1 en 2 b.v. een JabberID veld is toegevoegd aan het database schema dan voeg je die toe met ALTER als je van versie 1 naar versie 2 gaat en je dropt dat veld weer als je terug gaat naar versie 1.

Alleen lijkt me dat je zoiets niet zover wilt automatiseren. Met een handig tooltje de hele site gelijktrekken met SVN is al een twijfelactige actie. Je database ook op basis van SVN aanpassen lijkt me echt enorm eng. Verder lijkt me dat developers niet zomaar willekeurig dingen aan de database mogen veranderen en dat het gros van de aanpassingen geen veranderingen in de database nodig heeft. Ik zou het beheer van de DB dus gewoon met de hand blijven doen. Wel zo veilig. Beetje erg jammer als je je database door een domme commit fout helemaal om zeep helpt op je productie server...

  • Gerco
  • Registratie: Mei 2000
  • Laatst online: 02:46

Gerco

Professional Newbie

@bartvb: Ik neem aan dat TS niet gelijk HEAD gaat lopen uitchecken naar de productieomgeving, maar eerder de volgende versie/tag van het product.

Wat wij @ work hebben is het volgende: We hebben .sql scripts voor alle tables in version control staan en update scripts. Deze bevatten eigenlijk hetzelfde met een ander doel (waarom dat precies zo is weet ik ook niet). De .sql scripts worden gebruikt om de database te maken als je een nieuwe installatie gaat doen en bij een update worden (jaja) de update scripts aangeroepen om de velden toe te voegen.

Zo'n update script ziet er dan zo uit:
code:
1
2
3
- Als veld x in tabel y nog niet bestaat
- Maak veld x aan
- Doe wat zwarte magie om de goede waarden in dat veld te krijgen

Je zou voor een downgrade gewoon een tweede script kunnen maken wat de wijzigingen weer terugdraait, inclusief data conversie indien dat mogelijk is.

- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!