This project is read-only.

Feature Request: Allow user to determine when to generate a new installer version.

Jun 29, 2010 at 3:27 PM

The ability to automatically create database installation / upgrade projects is simply outstanding! However, I do have one issue with the current implementation. Our team has been learning the nHydrate tool and in turn has generated numerous upgrade scripts (over 100 at this point). It would be a nice feature if nHydrate would align the upgrade scripts to a "database version" field that was user definable on the top-level database in the .wsgen model file. That way, each successive code generation would simply update the database script associated with the current database version and only create a new script if the database version has been updated by the developer. This would eliminate the numerous unused scripts that are created during the initial database design phase. Thanks!

Jul 1, 2010 at 5:30 AM

Perhaps I am not understanding you correctly but there is a database version already. Please look in the model root object's properties for version. If you look at the extended properties of SQL database that was created or updated with the nHydrate database installer, you will see versioning and model information as well. Each time the installer is run, it checks the current database version and upgrades from that point forward. If there are too many upgrade SQL files then simply delete the empty one (if there are any) and combine some of the others. The file names generated in a versioned format you have no doubt noticed and only the necessary ones are run when upgrading a database.

Jul 1, 2010 at 1:30 PM
I understand that the database contains a version. My concern is the constant regeneration of upgrade files that are added to the installer project. When working under a source control tool this can be cumbersome as I would either need to add every one of these files to source control or constantly delete the files till I am ready to deliver a release version of the code in which case I would want to generate a new upgrade script with a matching version number and then remember to manually add that file to source control. This is not a show stopper but any means but more of a nuisance and a manual step that must be managed during our development process.
Dec 3, 2010 at 2:39 AM

I can see how this can be annoying but this is the architecture right now. This is needed because people do change something about their schemas between generation and write custom SQL code too. We might look at some alternative functionality in the future but for now this is what we have.