Forums

by Craig Shearer >> Mon, 7 Feb 2000 2:29:58 GMT

In the development environment we really need some sort of progress dialog on the reorg process.

This would include (at least) the class being processed (or is it done on a map file basis?). And, if possible, a percentage complete.

Even nicer would be some sort of estimate as to the time required to complete the reorg.

Sometimes performing a reorg seems to go off into never-never land and you have no idea how long it's going to take.

Craig.

by David Mitchell >> Mon, 7 Feb 2000 3:15:25 GMT

I agree.

Also, sometimes you will make a change to a class, and JADE will tell you this requires a reorg, continue? And gives you yes or no. How about saying "This requires a reorg, perform it now?" Yes/No/Cancel. So you would click yes and it would reorg for you, No, the change would still be made, but you would need to activate the reorg manually, or cancel would not make the change to the class.

--
David Mitchell
JADE Kid - 1998
www.jadekids.com

by Robert Barr >> Thu, 10 Feb 2000 22:02:58 GMT

Sometimes performing a reorg seems to go off into never-never land and you have no idea how long it's going to take.

Fair enough if you are reorging a single class.

However a warning for those new to JADE (or databases) - although JADE seems to make data reorg a trivial exercise, reorging multiple changes
is really living on the edge. A reorg can fail for valid reasons - safer to apply and reorg one change at a time, otherwise you can end up doing
a lot of JadeScripting to fix up the data!

Of course, it's better again to get your model design right before you populate it! Easy to say, I know... but if reorgs are a big part of your life, then take a step back ...

by Carl Ranson >> Thu, 10 Feb 2000 22:19:03 GMT

The problem I have with reorgs failing is that they provide little to no information about what went wrong or how to fix it.

If a reorg fails because a key field now needs to be unique, for instance, we should be told that "duplicate key detected for object <x.x> inserting into collection <y>" or something.

A lot of the time I don't care about the data being reorged. I wonder if it would be possible to have a "delete instances of class x instead" option? This would provide a fast workaround for some reorg failures.

CR

by Robert Barr >> Fri, 11 Feb 2000 3:48:49 GMT

The problem I have with reorgs failing is that they provide little to no information about what went wrong or how to fix it.

The reorg log contains the diags, but is often on another disk on a remote machine - it should really be 'in your face'. I have heard, on good authority, that reorg error reporting is going to be improved soon, ironically because (to some extent at least) there can be too much information in the reorg log.

A lot of the time I don't care about the data being reorged. I wonder if it would be possible to have a "delete instances of class x instead" option? This would provide a fast workaround for some reorg failures.

Carl, I suspect (hope) you are modelling in development when you "don't care about the data". The familiar desire to delete all instances (usually reference set data) is sometimes harder than it sounds, and you end up hacking around with jadescript for longer than you would really like to to remove instances and restore references. Using ...instances.purge can cause problems as this collection isn't 'updated' until transaction commit. A tip I heard is (during development only, of course) that you can use jdutil to delete the entire map file - a quick and effective way to purge all instances (assuming those you want to purge are defined in a particular map file).

While on the subject of reorgs, it's probably worth highlighting that a schema update containing consolidated reorgs should never be applied to
a production system before:
1) their application has been successfully tested on a copy of the production sytem, and
2) you have a backup of the production system - if the reorg fails after your schema changes have been applied, then you have no production system, and nowhere else to go but the backup.
(This isn't just JADE - this is any database, where, if multiple accumulated reorgs complete okay on development data, this is no guarantee that they will complete okay when consolidated into a single schema update on a different (production) data set).