add_acq_config_group update missing from 2.2-2.3.0 upgrade script

Actually, it should have been added to the 2.1-2.2 upgrade script. The 0715 upgrade was cherry-picked to rel_2_2 but didn't make its way into the upgrade script.

Testing upgrades from 2.2 - 2.3 wouldn't have caught it because the acq settings_group is in the seed data for 2.2.0.

This seems naggingly familiar for some reason.

I've pushed a branch that addresses this problem:

See user/dbs/fix_upgrade in working for a fix for master - a series of five commits. I had to copy the 2.2-2.3.0 script from the tag into master to begin with, and then applied the 0715 update.

Similarly, see user/dbs/var_upgrade_2_2 in working for a fix for rel_2_2 - a series of 3 commits.

In regard to:

2e91c29 2012-09-26 Add an explicit "set eg_version" at start of upgrade script <email address hidden>

My understanding of the purpose of the eg_version variable is to inform the scripts what version they are being applied to, not the version they are building toward. In other words, 2.2-2.3.0-upgrade-db.sql, should we not set the eg_version to 2.2.X instead of 2.3.0? I had assumed we didn't stamp the upgrade scripts like this because the source eg_version could differ depending on when it was applied (allowing the individual updates to occur or not, depending on whether they have since been superseded).

Hmm, related, I wonder if this:

INSERT INTO config.upgrade_log (version, applied_to) VALUES ('2.3.0', :eg_version);

...should in fact be the very last line of 2.2-2.3.0-upgrade-db.sql, instead of the first (or near the first), since the DB is not yet at that level until the script completes.

I don't see any actual advantage to the eg_version stuff in practice; almost anyone that comes into the IRC channel is told to use eg_version="NULL". I'd be happy to set it to that, actually.

Oh, and I based my decision on 2.1-2.2-upgrade-db.sql, which sets eg_version to "2.2.0" at the very beginning of the script. If that's wrong, I guess we should fix that too.

For clarification only of the original intent of eg_version, it was meant to be used as a per-instance troubleshooting datum. Say a site had over time, locally backported several DB-level fixes, one could tell not only at what time (which is indicative of, but not declarative about), but specifically which version they were running when the backported update was applied.

For sites that always runs only full releases (which hopefully will become more common, but is not the rule yet) this is less important, but IMO still useful. For parity with with the intended use, I would agree with Bill, that the applied_to should be set to the new version only at the very end of the upgrade.

Doing that would also allow us to move towards a smarter upgrade process (building, likely, off the update_db.sh dev tool) so that partial upgrades can be repaired and restarted from whatever point they reached, instead of potentially failing near the end of a big, multi-hour mostly-single-transaction SQL script.

As for deprecation and supersesion, a likely use case is one where the version upgrade script is, effectively, an upgrade chunk script that supersedes the version-intermediate chunk scripts that do things like fire off re-ingests, so that those expensive, recurring data-update processes only happen once at the end when you're doing the X-to-Y all-at-once upgrade, instead of trying to follow master.

Does that help, and/or make sense?

Well, we can make the future look like Bill and Mike's vision if that's what everybody likes. The past looks like Dan's. All the code here has been pushed now.