[SQLServer] Subversion synchronisatie *

[GrimaceODespair]

Ik ben op zoek naar een oplossing om op een handzame manier Stored Procedures in een SQLServer database te synchroniseren met subversion. Er is hierover echter ontzettend weinig te vinden. Enkele commerciele producten (heb ff de links niet meer bij de hand, available on request) bieden dit aan in een pakket met nog veel meer features, maar dat is overkill voor mij.

De meest gegeven tip is: hou de SP's bij in SQL Scripts die je incheckt. Gebruik Query Analyzer om de SP's bij te werken. Ik zou echter graag een iets handigere oplossing hebben, liefst waarbij ik gemakkelijk ook kan checken of een DB up to date is.

Nu zit er in de Microsoft SQL Resource Kit een tool met broncode die SP's op een VSS-database synchroniseert. Echter, die resource kit is oud (juni 2001) en de download link op die pagina klopt dus niet meer. Via ons MSDN abo kan ik de kit ook nergens vinden voor download.

Ik ben erg nieuwsgierig hoe dat ding in elkaar zit. Of hij gebruik maakt van de VSS stored procedures die in SQL Server zitten, of zelf de VSS toegang regelt. Als ik de broncode heb, kan ik ook zien of het gemakkelijk om te zetten zou zijn.

Dus, voordat ik hem via MS zou bestellen (als dat uberhaupt nog mogelijk is):

• Heeft iemand ervaring/tips ivm de StoredProcBuilder?
• Heeft iemand die broncode nog ergens liggen?
• Heeft iemand nog een andere nuttige suggestie om SQLServer Stored Procedures met Subversion te combineren?

[MSalters]

Volgens mij is de meest eenvoudige aanpak om zelf een klein programmatje te schrijven:
Connect met SQL, execute iets als

SQL:

SELECT o.id, o.name, c.text
FROM sysobjects o 
  INNER JOIN syscomments c ON o.id = c.id
WHERE o.type = 'P'

Dit geeft je de "file" die je in SVN wil beheren. Je moet natuurlijk wel de SVN metadata bijhouden wat je wanneer uitgecheckt hebt. Normaal gesproken (dwz met de standaard SVN client) komt dit in .svn terecht. Ik zou niet direct weten hoe je dat het beste naar SQL kunt mappen, maar het ligt voor de hand om een tabel SVN te maken met kolommen file_name en file_content

[GrimaceODespair]

MSalters schreef op 11 november 2004 @ 23:59:
Dit geeft je de "file" die je in SVN wil beheren. Je moet natuurlijk wel de SVN metadata bijhouden wat je wanneer uitgecheckt hebt. Normaal gesproken (dwz met de standaard SVN client) komt dit in .svn terecht. Ik zou niet direct weten hoe je dat het beste naar SQL kunt mappen, maar het ligt voor de hand om een tabel SVN te maken met kolommen file_name en file_content

Ik heb heel even zitten neuzen in de de VSS stored procedures, en die gebruiken volgens mij de dtproperties tabel om VSS informatie bij te houden.

Als ik zelf geen zin heb om een interface te bouwen, zou het natuurlijk het mooiste zijn als ik dicht kan gaan aanleunen tegen de VSS implementatie. Ondanks dat er geen 1-op-1 mapping bestaat van het VSS locking model naar het Subversion edit model, kan ik dan wel genieten van de MS tools die met VSS om kunnen. (wat betreft die mapping, dat is iets wat PushOk al voor elkaar heeft).

Dat zou willen zeggen (misschien tricky, maar daar gaat het even niet over) dat ik
de VSS stored procedures moet herschrijven om subversion aan te spreken.

Bovenstaande allemaal bij wijze van brainstorm.

[Soultaker]

Dit lijkt mij een typisch geval van KISS: keep it simple, stupid!

Je wil je stored procedures (net als de lay-out van tabellen en datatypen, wat mij betreft) toch ergens in tekstuele vorm bijhouden. SQL scripts lijken me dus een prima plek om ze in te schrijven.

Checken of een database up-to-date is is wel lastig. Je zou er zelf een tooltje voor kunnen schrijven; je voert de scripts uit op een test-database en je vergelijkt de structuur daarvan met de structuur van je 'echte' database. Dat werkt alleen voor scripts die alleen databasestructuur aanmaken (tabellen, datatypen, stored procedures, etcetera). Eventuele waarden in de database zullen natuurlijk niet zo vergeleken kunnen worden (maar je moet de inhoud van een database ook waarschijnlijk niet in een source repository stoppen).

[Orphix]

VS.NET heeft trouwens ook een 'Database project' project-type (in de map 'Other projects'). Ik heb er zelf niet mee gewerkt, maar ik heb wel ergens ooit gelezen dat je daarmee gemakkelijk je database kan updaten vanuit je scripts, of je scripts laten genereren vanuit je database.
Misschien het proberen waard.

[GrimaceODespair]

Soultaker schreef op 12 november 2004 @ 01:33:
Checken of een database up-to-date is is wel lastig. Je zou er zelf een tooltje voor kunnen schrijven; je voert de scripts uit op een test-database en je vergelijkt de structuur daarvan met de structuur van je 'echte' database.

Hmja, zo ver wou ik zelfs niet gaan. Ik ga ervanuit dat ik de versienummers ook in de database opsla. Het nadeel is dan niet op werkelijke inhoud vergelijkt, het voordeel dat je minder programmeerwerk hebt (alhoewel).

Overigens vind ik het echt vreemd dat hier zo weinig oplossingen voor bestaan, of doe ik nu een boel commerciële paketten te kort? Het synchroniseren van een database met een versioning systeem lijkt me toch vrij banaal?

En ja, ik kan gewoon stored procedures in tekstbestanden stoppen en inchecken, en dat werkt ook vrij aardig (als je jezelf die methodiek aanleert), maar ik wil gewoon net iets meer

Orphix schreef op 12 november 2004 @ 01:56:
VS.NET heeft trouwens ook een 'Database project' project-type (in de map 'Other projects'). Ik heb er zelf niet mee gewerkt, maar ik heb wel ergens ooit gelezen dat je daarmee gemakkelijk je database kan updaten vanuit je scripts, of je scripts laten genereren vanuit je database.

Hmm... nog nooit gezien (weet even niet of ik mij daar erg hard voor moet schamen). Ziet er interessant uit! Ik ga het zeker bekijken, tnx.

[ Voor 22% gewijzigd door GrimaceODespair op 12-11-2004 02:07 ]