DB upgrades should not force customers to edit source code
Description
Activity
amberg1 February 3, 2011 at 5:21 AM
Jira is old. Feel free to re-open if motivated to write the tool mentioned
Ray Davis September 1, 2009 at 12:01 PM
There's no chance that I'll get to this any time soon, so I'm unassigning myself. Feel free to pick up the task if you're interested, or close as "Won't Fix" if you want to get it off the pending list.
David Haines June 18, 2008 at 11:51 AM
You are ahead of me Ray. Having a standalone utility is just what I had in mind.
Ray Davis June 18, 2008 at 8:59 AM
The goal of the "assembly"/"appassembler" approach would be to get a standalone executable which could be run without access to the source code.
That hasn't been a pressing priority for us because we already have a checkout of the source code on our production systems. Rather than try to take a snapshot of all WARs in place and then copy them from cluster to cluster, we use a script that checks out a tag and builds and deploys in place. Since Maven is guaranteed to be there, using it to perform non-SQL maintenance tasks isn't a huge amount of extra overhead. But I agree with you and Stephen that more options are needed.
Especially for "selective" or optional jobs, and especially once I or someone else gets to SAK-13696, the Quartz job approach is awfully appealing, although obviously it doesn't help with non-optional upgrade-related conversions.
David Haines June 18, 2008 at 8:34 AM
Is it likely that the maven version would easily translate into a maven-independent version? Some installations don't typically allow access for production changes from development environments. It sounds like extracting something using the antrun plugin should be easy enough if it doesn't depend on some other maven functionality.
Before 2.5.0, Sakai's only standard support for database schema updates was through static SQL scripts. This clearly isn't sufficient when more complex conversion logic is required. Probably in an attempt to meet such needs, a new "conversion utility" was added to Sakai in SAK-12031. However, the implementation has a number of drawbacks:
A Unix shell script is used, which forces customers to deal with cross-platform issues such as classpath separators and the location of executables.
Database settings are hard-coded to be read from the same properties file that contains SQL statements. This tightly couples extremely context-sensitive properties with programming logic and forces customers to edit source files for every DB effected.
Rather than making DB modifications from a running Tomcat server, the goal is to run Java code from a command line with the proper libraries on the classpath. To set the environment up correctly, the current approach forces customers to rename or copy a Maven file to create a bogus (non-web-application) WAR and then run the script from the exploded version of the WAR.
(Update: That last bullet point was based on the more recent SAK-12239 branch, not on the code in the trunk. The trunk's shell script doesn't specifically require building and exploding a bogus WAR. However, since it bases its class path on JARs installed in the local Maven repository cache, it still does require running Maven against source to populate the cache.)
The current approach should be revised or replaced to reduce the overhead of DB upgrades.