On 09/22/2010 05:59 PM, Adam Heath wrote:
On 09/22/2010 05:53 PM, Adam Heath wrote:
On 09/22/2010 05:44 PM, Jacques Le Roux wrote:
From: "Adam Heath" <doo...@brainfood.com>
On 09/22/2010 03:33 PM, BJ Freeman wrote:
Am it to gather by this that you can do a direct SVN update and all
your
customization continue to work?
say from 9.04 to 10.04
Ofbiz has never supported upgrades. I agree with BJ here.
Database tables can change. Not all changes are automatic. Such
changes are not listed in a simple place(in the source).
Values in tables can change. No upgrade conversions are
provided(again, in a simple place).
Is this useless?
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
Pretty much. Way to hard to follow. Too much information. Needs more
automation.
And I'm a fairly technical ofbiz guy. And where is this linked from?
I should rephrase that.
That document is too techincal, even for those who are quite familiar
with the internals of ofbiz.
People just doing plain jane installs will have no idea how to deal with
that document.
What we need to do, is become stupid. Forget everything you know. Then
try to read that.
The other issue is when did ofbiz last *officially* release? Waiting too
long to release gives *large* changes that have to be done manually.
Plus, if someone(brainfood or bj) has based an install off of an svn
*snapshot*, then we can't expect the project to help us much when doing
upgrade conversions.
Here are my thoughts on a more automagical way to do upgrades.
When a change is committed, the author may not be aware of the
implications of that change, as far as upgrades are concerned. Even
if the author is aware, and they provide some kind of upgrade script,
the script itself could be buggy, so a new version would need to be
created. However, you can't go back in time to fix the previous
script. This means the upgrade scripts need to be maintained
out-of-band, while somehow referencing the previous change(by id, by
date, by version, or something).
Next, is that you don't need to be concerned with all possible
variations of upgrades. A->B->C->D is all you need to be concerned
about. There is no reason to have a script to go from A->D.
If ofbiz stores the installed version id somewhere(along with the date
*of the version*), and then compares the new version id(along with the
date), it can fetch the series of scripts nescessary to upgrade
incrementally.
My proposal, is for every commit that requires some upgrade support,
to have an external repository(could still be hosted on
svn.apache.org, could even be in each particular branch); let's say
$OFBIZ_HOME/upgrade/scripts/. At that location, there will be a text
file registry, that lists the original revision id(doesn't have to be
the svn id, it's just completely freefrom), and the date of the
original id. It would also list the script to run to do any upgrade
processing.
Ofbiz would then just run the scripts in series. Or, the admin would.
This in-place upgrade system would probably *not* use much ofbiz code.
Or, it would have to use a very small subset. I'm not entirely
certain about how the system would actually function, other than the
high-level series of steps I've outlined.
