hook in into script generation

wimrey

Hey,

is it possible to change the way scripts are generated. In our case we use a variable to replace the schema name with the schema name of the database being updated. (we utilize ready-roll in a multi-tenant application). eg:
we have a development schema name, say [DEV]. In every script we generate with ready-roll, we have to change [DEV] to [$(SchemaName)]. When we deploy to a database, we specify the schema-name with the variable. This all works, but

it would be handy if we, somehow, could replace our schema-name with the variable name. Everyone can use the same development schema name if it would be something 'hard coded' eg: always replays [DEV] with [$(SchemaName)]. Is this something that is possible?

best regards,
Wim

dnlnln

Unfortunately there is currently not a way to hook into script generation.

Alternatively, if you were to keep the constant in your scripts, i.e. [DEV], you could use the post-build event to replace the constant with a variable in the output package. Would that be an acceptable solution?

wimrey

Hey,

we could try to implement that with a custom build event. I'm a little worried about the performance once we get to a lot of migrations, but it might be worth a try. If we write a custom simple console application to do that job, we could even do some checks to only check the files that are modified within e.g. the last week. I guesse we will try to implement something like this.

best regards,
Wim

dnlnln

Great, please let me know how this works out and whether the build-time performance associated with the string replacement is acceptable.

wimrey

Hey,

so far, the solution doesn't slow down compilation time a lot. Still a bit worried, because we only have 30 migration right now, but we could always alter our program to only check the last migration versions.

best regards,
Wim

dnlnln

Hi Wim,

Something just occurred to me: if you decide to use the patch deployment method we discussed in this thread, your string replacement tool will only ever need to parse the diff of migrations. So the amount of parsing it should need to do should remain quite minimal (providing you only parse the output files and not the project files).

wimrey

Hi,

In the end, we couldn't use the patch deployment script, because that script get's locked to 1 specific database. Also, I implemented the replace on the original migration scripts that get checked in into source control. That way, the scripts in source control are the correct ones. That gives me a better 'feeling.' As a performance safeguard, we only check for replaces in script files that were changed/added to the developer system in the last 7 days. The console application that does the replace, also runs as a pre-build event. That way, the generated output is correct from the first build, instead of the second (when using an after build event)
we had our first release to production with the readyroll system. We updated 220 databases in 1h20min. We will be working on reducing the number of GO statements to reduce this amount of time, but overall, it went without any major issues

dnlnln

Hi Wim,

Thanks for getting back to me. I appreciate that the patch approach wasn't quite what you were after; the per-database validation is needed in order to ensure that the script is applied to the right target (as one database may only have a subset of migrations applied to another, and vice versa). However if you're confident that all of your target databases are in-sync, then you could simply remove the validation at the top of the patch script prior to executing it.

Although it sounds like you're reasonably happy with the patch approach so far, but please let me know with how you get on with your script modifications.