Something my team is beginning to do with our system, is to create a pair of scripts, one of which applies any changes to our database (particularly focussing on ALTER TABLE statements, to add new fields along with rational default values and constraints), and another to deal with changes to our code (all written in Perl+SQL+Javascript - so you wouldn't be interested in the details). If the update process is automated, it really doesn't matter how many changes there are, because the script handles it all. Of course, this doesn't help in situations in which one takes the approach of storing specific data as a hash of the data rather than the raw data, and then one decides to use a different hash algorithm to make the hash (passwords are an obvious example). But in such cases, one ought to do a couple things: 1) provide an option to allow use of the original algorithm, and 2) provide an option to let the user use the new algorithm when the old password expires (or one can automate that, but that requires a little extra code). This isn't all that new an idea as I recall using diff on C/C++ files what seems like eons ago. But perhaps it is time that such an idea was applied to OFBiz? Of course, that means that someone needs to take responsibility for maintaining such a pair of scripts.
Just a thought... Ted On Sat, Sep 14, 2013 at 7:56 AM, Jacques Le Roux <[email protected]> wrote: > To reassure you Skip, OFBiz is more mature now, there should be less changes > the next time you will do it. > Except, if we want to take advantage of Java 8 : > http://www.techempower.com/blog/2013/03/26/everything-about-java-8/ > Of course, updating more often should help... > > Jacques
