Comment 23 for bug 925776

Ben Shum (bshum) wrote :

So, for the upgrade directory, those changes are only applied sequentially for folks upgrading their database over time. The various upgrade script files are later combined to create the version-upgrade script files when releases are cut. Generally, a change to the database involves altering the stock function in the regular files used and then also creating an accompanying XXXX.change_to_be_made.sql upgrade file in the upgrades directory (which is later stamped with the next available number in the sequence by the core committer putting it in for master). That way, new Evergreen installations will just make use of the stock DB files and using the latest version of the SQL vs. existing and running systems that need to be upgraded making use of the small upgrade files in necessary sequential order.

For example, in our case, running a master system, we check for the most recent numbered script in our config.upgrade_log and then we run all the scripts numbered after that. So like if our last one was 0820, then we'd run from 0821 onwards to get "upgraded". When the same function is changed multiple times over the course of many upgrade script files, that's you seeing the iteration of the feature/functionality over time as it evolves with new development and bug fixes.

So, generally speaking, I'd only include actual changed functions and new seed data in upgrade script files. You do not necessarily have to copy other upgrade scripts or replace untouched functions along the way.

I'll leave pgTAP test ideas for someone else who's more confident of that area to explain...