Forums

by Hayden >> Mon, 23 Nov 1998 6:28:37 GMT

Hi All.

I've just hit a bug in Jade which won't be fixed until version 5. It's the case of having subclassing between schemas, and the restrictions
of loading that higher level schema.

One of the ways of fixing it to is export all data, and import it into
a blank upgraded database.

So my question is, has anyone tried or succeeded in writing data export/import routines for all instances of all classes (or even most
- more than one, with 1:M relationships) in your database?

Any ideas?

I could see this sort of this earning some extra cash if it was to be
a 3rd party Jade add-on....

Thanks Heaps
Hayden McInnes.

by Martin Sparkes >> Mon, 7 Dec 1998 1:15:13 GMT

Any ideas?

I could see this sort of this earning some extra cash if it was to be
a 3rd party Jade add-on....

Thanks Heaps
Hayden McInnes.

We have written some import/export data which has been working since Jade 3 days. It assumes that the data classes decend from one common base class, and will automatically resolve the correct import order to successfully handle the referencing issues. We would consider onselling the code concerned if you are interested.

Martin.
SSI Ltd.
ssi@xtra.co.nz

by Hayden >> Tue, 8 Dec 1998 13:35:05 GMT

We have written some import/export data which has been working since Jade 3 days. It assumes that the data classes decend from one common base class, and will automatically resolve the correct import order to successfully handle the referencing issues. We would consider onselling the code concerned if you are interested.

Very interested Martin !

But what do you mean by "decend from one common bas class" ?? Don't
they all decend from Object ?? Or would we be required to subclass everything from your "Export" class, which would be subclassed from Object...?

That would be a lot of work at this stage.... But it's good to know
that it's been done.

Any more info you could give me would be appreciated, and I can pass
it on to the rest of the gang and the lads who control the purse
strings. My email is hayden@focussoft.co.nz

Thanks.

by Paul Mathews >> Wed, 9 Dec 1998 6:15:11 GMT

Our Primary requirement was the ability to transmit demonstration and setup data between different installations of our applications. The
code is available from our website free in cmsystemsgroup.com.au downloads.

Belows is copied from the documentation of what we have done.

The CMBackup Class methods and associated Forms FCMBackup and FCMClone
is developed and tested in our Planning
Board product, which has quite an extensive set of classes and relationships. It also stores oleobjects.

There were three goals.

o - make this class as standalone as possible. This has been well achieved.

o - Be able to distribute demonstration data that could be easily uploaded, based on the structure and names of classes and their properties rather than their class numbering which can be different
every time they are loaded.

o - Be able to clone a RootObject and all it's related Object prior to
a demonstration.

A series of solutions evolved,

1) Backup All those User Defined Classes which have permanent
Instances.

2) Backup from an Object all Related Objects (eg a RootObject).

3) Clone a RootObject, evolved from 2)

4) Weaknesses were found in 1) when oleObjects were being used as they are not User Defined Classes.

Replaced 1) by using the approach of Backing Up all Objects from
the Global Object and drilling down.

The advantages to date of the approach from 2) down when things have
not worked, they have indicated to date weaknesses in design.

The code used for 1) has been kept but is commented out.

Many things were learnt in the internal structures of Jade whilst
doing this,

some key JadeScripts where used to show the properties and methods of Classes not well documented or documented at all.

o - propertyNDict
o - methodNDict

and there is an indispensible method getInverses for Class ExplicitInverseRef in CMSchema to get the value of a protected
reference !

Working out a strategy to backup collections was experimental.

Three Types of files are used to store data .ctl, .txt and .bin and
when loading a .log file is updated.

There 2 stages to reload data;

1) For each dumped objected, create a new object in the appropriate class, load it's properties, and build up a cross reference collection
of oldOid and newOid.

2) For each dumped object, rebuild it's references and collections
using the cross reference collection.

NOT WANTING to worry about delimiters of any kind all String fields
are dumped to the .txt file, with 2 references, starting position and length.
Binary Data is dumped using the same approach to the .bin file.

A number of things, were learnt about Jade's flat file handling.

1) You can reopen a flat file and modity any portion of it.
2) Following on from 1), if an existing file is to be output again,
purge it first.
3) Close a flat file specifically or by deleting the transient File instance, so it no longer appears to be in use.

Distributing Data to other sites - example

We needed this for our Planning Board application.

Now when the PlanningBoard is started for the first time with no Application Data,

You will be prompted with the message
<Restore from Distribution Data>
There is no Data in your Application.
Do you want to Restore Design Data ?
if you do nothing, basic data will be defaulted.

PRESS YES
Ensure you select the Restore TAB !
Use RadioButton All Data.
Browse for file PlanningBoard.ctl (also uses PlanningBoard.txt which should be in the same
directory).