Forums

by tyc >> Sat, 23 Nov 2002 3:32:35 GMT

Hi Jade Developers,
We recently met with a lot of problems with patching of our clients
and found that we don't fully understand the patching facility of
Jade. Hope the experience 'patchers' can advise on the points.

We did a list of test to confirm and need you all to advise on these points.

Test Done on : Jade 5.2.8.246, Win2000+service pack 3, P4 PC, single
user

Procedure :
1) Have 2 exact same systems [ /system1 and /system2] ]
2) Enabled patch control function and set both to patch no. 300
3) Run /system1 and go thru the list of operation
4) generate patch file from /system1
5) load patch into /system2
6) Log the results of the test

Seems like our test showed that patching seems to give more problems
than solve.. All our tests seemed to have failed..

Results:
1) Renamed HRSkillCD Class with 2 references to HRSkillCDMy
In system2 after patching, we found both Classes still exists
instead of one with the references intact.


2) Renamed allFixedItem_SRMast in DSSProfile_SR. [without references]
In system2 after patching, we found that both of properties exist instead of just the renamed one.

3) Renamed clockAddr(String) in TMTemp to clockAddrMy [with
references]
In system2 after patching, both property appeared, but clockAddr
does not have reference now. Technically we just have to delete the clockAddr to make it right, but doesn't look well on the patching process.


4) Renamed inverse pproperty imyTmParam_Date_StaffID in TMTemp to imyTMParam_Date_StaffIDMy. [with References]
In system2 after patching, both are in the TMTemp and both of them
have the references

5) Renamed TMTempCard [with references] to TMTempCar_My.
In system2 after patching, both Classes exists but TMTempCard_My does
not have references.

6) Deleted SAVldAgent [of superClass:ValidateAgentX without any references
In system2 after patching, the SAVldAgent still exists there even
though it was deleted in system 1

7) Renamed mkdAPMast in FrmAPAgePrint to mkdAPMast_My [without any references]
In system2 after patching, both the mkdAPMast and mkdAPMast_My
exists.

8) Deleted table tbObjectAPBatch in FrmAPBatchPrint [without any references]
In system2 after patching, this was the only one that seem to
perform correctly.

9) Deleted form FrmAPInv with references
In system2 after patching, it exist still

10) Renamed form FrmAPMonthEnd with references in Painter to FrmAPMonthEnd_My
In system2 after patching, both of the forms now exists with all the references

Judging from all the tests, the renaming and deletion doesn't seem to
be extracted out thru patching. So in the system to be patch it might create a lot of errors after loading the patch in, even though the
base system is correct.

Can anyone verify these points, and advise on how to properly patch
our clients. This has caused a lot of fear in patching for us.

Thanks in advance and much appreciated

Regards,
L.C. Lim

by allistar >> Sat, 23 Nov 2002 8:56:14 GMT

Hi there,
Jade treats renaming as the same as removing and adding. So in item 1 above renaming the HRSkillCD class to HRSkillCDMy appears to the Jade loader that you have deleted the class called HRSkillCD and added a new class called HRSkillCDMy. As you have experienced te old class still exists.

Classes will not be deleted in a schema load if:
- it is a partial schema extract (as opposed to a complete one)
- the class has references to it in the system you are importing into.

Properties will not be deleted in a schema load if:
- the property has references to it (i.e. inverses) in the system you are importing into.

This behaviour explains what you are experiencing in points 1 through 10 in your original message.

Here is how we get around this:
1) we never rename classes that are already on one of our sites
2) when we delete classes we do it with the understanding that they won't be deleted on our sites.
3) we never rename properties, and if we want to achieve the same thing we add a new property, run a script on site that copies the data from the old property to the new property, and then delete the onld property.
4) We never do full schema imports into our sites (it just takes too long) 5) We don't use the Jade patching system

We use a combination of deltas and our own "class locking system" that automatically creates a .unl file for us that we generate a gauranteed accurate extract of the changes made. Upgrades/patches are automatically made into compressed "packages" that can be applied to site with the click of a button.

(BTW: anyone interested in our Jade source code management system feel free to drop me an email: allistar AT greentree DOT co DOT nz. It has saved as unmeasurable cost in supprting and deploying our Jade based software as well as streamlining Jade development with a large number of (often remote) developers).

Regards,
Allistar.