Thanks for the proposition Ted, Unfortunately, we are not missing good ideas, but good wills...
Jacques Ted Byers wrote: > 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 > <jacques.le.r...@les7arts.com> 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
