Modification Attribute without Reorg process

[ConvertFromOldNGs]

by Din >> Thu, 2 Apr 2009 11:41:06 GMT

Hallo Jade support

I have a question about modification attribute.
Is it possible Changing type of Attribute ( e.g from String to Int ) without any reorg. database process ?
This is important because I want to keep the persistent data from
the old schema.

Thanks for any clue
Din

[ConvertFromOldNGs]

by cnwjhp1 >> Thu, 2 Apr 2009 21:48:42 GMT

Could you use get and set methods which do the conversion at runtime?

[ConvertFromOldNGs]

by Din >> Fri, 3 Apr 2009 18:28:38 GMT

what is name of method which do the conversion at runtime ?

Thanks for any clue
Din

[ConvertFromOldNGs]

by Jade Support >> Sun, 5 Apr 2009 23:23:07 GMT

You will need to cast (typecast) the attribute to the specific type. A simple example of this using the suggestion of get() and set() methods follows:

Assuming str is a local attribute of type String...

getStr() : Integer;begin

if self.str.isInteger() then
return self.str.Integer;
else
return -1; // Error.
endif;
end;

setStr(pInt : Integer) updating;begin

self.str := pInt.String;
end;

For more information on casting see 'Type Casts' in the JADE Developer's Reference, page 58. Specifically the section on 'Converting Primitive Types'.

Thank you,
Jade Support.

[ConvertFromOldNGs]

by Patwos >> Mon, 6 Apr 2009 4:52:18 GMT

If your main requirement is the retention of your old data, rather than avioding a reorg, then you could consider renaming your existing property and adding a new property of type Integer. Then, adjust all your code that references the renamed property to reference the new property and adjust it as applicable to deal with the changed type.

Can I ask why do you want to retain the old data? Your response to this question may alter the responses for any suggestions that have already been made.

Also, you may need to write a "fixup" script to populate the new field with appropriate values based on the old property's value. If these changes need to be deployed to "production" systems, then you'll also need to include a Jade Command File (jcf) to perform the property rename on your production systems prior to deploying your next release.

Hope that helps,
Pat.

[ConvertFromOldNGs]

by Din >> Tue, 7 Apr 2009 11:01:37 GMT

Dear Patwos

Thanks for your solution.

Regarding to your question, .....
I should say, I am student and doing some research in Jade.
It will be nice if Jade has feature (let say) retention data.

Do you have contoct to somebody in "production" system in Jade ?
(so, I can contact him/her personally due to this issue).

thanks
Din

[ConvertFromOldNGs]

by Torrie Moore >> Tue, 7 Apr 2009 21:11:22 GMT

Hi Din

We are faced by this issue from time to time in production systems. We take the same approach as outlined by Patwos. In a little more detail

1) Add new properties with the required data types to the system. This will require a reorg as we are changing the structure of the data. This is what the reorg process does. It will retain the data in existing properties. This is normally done via a schema load.
2) Load and run a script (You can write a JadeScript) that will update the data in the system in your scenario, set the new integer property from the string property. We would run this using the JadLoadb utility. For example, something like the following would work in your scenario

vars
oObj : SomeClass;
begin
beginTransaction;
foreach oObj in SomeClass.instances do
if oObj.stringProperty.isInteger
// String property is an integer
oObj.intProperty := oObj.stringProperty.Integer;
else
// String could not be converted to an integer. - Stop processing and abort.
write "Cannot convert data - String does not convert to an integer;
abortTransaction;
break; // Stop processing
endif;
endforeach;
commitTransaction;

3) Load the new schemas that use the new property rather than the integer one. If the old property has been removed from the class in this schema file then it will be deleted. (Another reorg)

To make sure that this process is robust as possible we would take a copy of the production system into a test environment and run through this process to ensure that there will be no unexpected issues. We would then repeat the same process on the production system. Our updates are done via scripts (we use a bat files and the Jade command line utilities (jdbutilb, jadloadb, jadclient etc.) so that exactly the same process is applied to the test system as to the production system. The process will include a pre upgrade backup in case something goes wrong and a post upgrade backup. We need to be able to restore to how things were before the upgrade if something goes wrong (pre upgrade) and it's often useful to have a backup after the upgrade so if the system fails following the upgrade, we don't need to repeat the upgrade.

If there are any data updates during an upgrade process, we will log any change we make so that there is a record of exactly what the upgrade process has done. This is normally done to a text file using the JadeLog class.

Hope this helps.

Torrie

[ConvertFromOldNGs]

by Patwos >> Wed, 8 Apr 2009 8:03:29 GMT

Din,

Are you able to expand on what you mean by retention data?

Pat.

[ConvertFromOldNGs]

by Din >> Wed, 8 Apr 2009 9:39:59 GMT

Dear Patwos and All

I wish, I could make it.
I am still working with this issue
But at least, we got a clue from Torrie Moore
I will back to you for new update.

What I need now is some literatures about core design of reorg database process.
So, is anybody can help me outside there ?

Thanks for any clue

[ConvertFromOldNGs]

by Dean Cooper >> Wed, 8 Apr 2009 9:57:12 GMT

There is a thorough discussion about versioning and reorg in the "Schema Evolution and Instantiation" white paper, here:

http://www.jadeworld.com/downloads/jade ... maEvol.pdf

However, there's nothing in it about "data retention" across a reorg. The suggestions from Torrie and Patwos are the way to go about doing that.

Dean.