Bilgin Ibryam wrote: > Inline > > David E Jones wrote: >> On Nov 27, 2009, at 2:14 AM, Scott Gray wrote:
>> We can move Old* entity to other files, but IMO they need to stay >> basically forever in order to maintain an upgrade path. Without them >> upgrading becomes very difficult. >> >> If there was a case where and Old* entity was replaced by another Old* >> entity (which was then in turn replaced by an entity currently in use) >> then maybe we could consider getting rid of one of them, but IMO we >> still shouldn't because it would mean that regardless of which one we >> get rid of a certain range of revisions will not be upgradeable to the >> latest revision. >> >> We could go down the path of requiring upgrades to go through a series >> of changes, like to 4.0 to then to 09.04 then to trunk (or whatever >> other release branches have been done). However, is it really that >> tough to keep this stuff around? IMO it is really not at all a big deal. >> >> If anyone is really bothered by messy stuff in the project then start >> cleaning up and modernizing older code, but please let's not get so >> aggressive about getting rid of stuff that is likely to be used. >> >> -David Upgrades from A to B to C to D to E: Don't try to be smart, and have an upgrade script to go to one of each of A to B, A to C, A to D, and A to E. Ofbiz should store the version at install time into the database. Then, during an upgrade, it would see the new version, and check for upgrade scripts by version. This might be an iterative kind of upgrade, or could be done with the dpkg compare-versions algorithm(I have a port of that to java code lying around here somewhere). Said upgrade scripts(services/entities) don't need to be available for general purpose use at runtime. They could be in alternative files that are only made available during the upgrade process. When a new item(entity or service) is installed, it should list an UpgradeArtifact for the MostRecent working version. Each UpgradeArtifact can then list another MostRecent UpgradeArtifact. During upgrade, ofbiz would scan all Artificates for any registered UpgradeArtifact, then follow the MostRecent UpgradeArtifact links, until it finds a MostRecent that is earlier than the currently installed version. Then, with this list of all UpgradeArtifacts, it would order then by version, and run them in series.
