Back-fill action_trigger.event complete_time values

[Bill Erickson]

Continuation of bug #1672824 which addresses the lack of action_trigger.event.complete_time values for grouped events, for consideration in 3.0.

Summarizing:

==
Is it worth adding an update script that tries to clean this up? If so, given the potentially large number of rows to update, should the update be spun off into a separate wishlist for 3.0?

Something along the lines of this?

update action_trigger.event set complete_time = update_time where state = 'complete' and complete_time is null;
==

We likely want this update to run outside of the main upgrade transaction.

[Bill Erickson (berick)]

Upgrade script pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1690418-at-event-set-complete

[Dan Wells (dbw2)]

I gave this script a go on our production server, and it updated ~200,000 rows in under two seconds. I know bigger installs will take more time, but even a factor of 10 or 20 feels within the range of a "normal" upgrade script.

For simplicity's sake, I wouldn't mind seeing this rolled into the parent bug upgrade script for all versions.

[Bill Erickson (berick)]

Assuming comparable delete times, It'll be >20 minutes here (136M rows). That may be an outlier (and I can always tweak the upgrade locally), but keeping the deletes out of the main upgrade transaction still seems like the better approach. I think it can be in the same script, just at the end, post-transaction.

[Bill Erickson (berick)]

And thanks for testing that Dan, because I had not collected any data yet to justify the concern. I'm trying a proper delete (w/ rollback) now on a test server to see what happens.

[Bill Erickson (berick)]

Noting that I meant to say 'comparable update times' not 'delete' times a few comments up.

[Dan Wells (dbw2)]

Well, I guess if 680x larger is on the table, then maybe this is the proper level of precaution :)