Warning: backported schema change to obs table

Apologizes for not noticing this earlier, but as part of TRUNK-3915, we are added a not-null constraint to the uuid column of the obs table.

Previously, we’ve noticed high performance impacts when trying to make schema changes to a very large table such as the obs table. I’m currently testing out the 1.10.4 platform release again a copy of our production database at UHM, (which has over 11 million obs) and the update did appear to work successfully, but not without hanging my development IntelliJ/Jetty instance in the process. I will add a warning about this to the 1.10.4 release notes.

At one time we were supposed to have a GSoC project for someone to hack on a something to address slow database upgrades, there are changesets that don’t necessarily need to be run before openmrs starts and there are those that need to be run before it starts. For the former, a possible solution is to run them in a scheduled task that gets triggered at start up so they run in the back ground after the openmrs has been started and as for the latter things get a little tricky.