Fools walk in where other fear to tread. LOL
It and setup are my two priorities at the moment.
like you I only have so much time, but I am plugging away at it.
I am sure if funding came about there were be many that would change
their priorities.
Jacques Le Roux sent the following on 9/26/2010 4:02 PM:
You are ideas sounds both interesting, but I wonder if we will ever have
enough commitment to do them...
Jacques
From: "BJ Freeman" <bjf...@free-man.net>
I think for the first cut I have simplified it both for the committer
and for the clients current version of ofbiz.
A webtools that goes to the Commit email archive and reads the commits
and compares then to the svn image of ofbiz and the Customize
components that are either in the component-ofbiz.xml or in hot-depoly.
the compare may be a little tricky but I think it is doable with regx
it will generate a report of its findings only.
at least that satisfies my current requirements to flag what I need to
look at.
the next cut would become more intelligent to suggest upgrades paths
based on the commit being processed.
or maybe using the commit number will look in the components patch
folder for a script for the upgrade provided by the committer.
or as you say have a location it goes to for updates that is not part
of the regular SVN image like the site is.
Could even put it under the site.
Adam Heath sent the following on 9/23/2010 9:33 AM:
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.
