JADE Environment Development Ideas

What's new in the upcoming JADE release?


The JADE 2022 release meets tomorrow’s business demands.

Start your update to JADE's latest release

Smart extract

Extracting code from schemas reliably is a difficult job. If I want to move a bunch of classes from one schema to another this is a difficult task as there are required dependencies between classes which must be extracted together to allow the extract to be successfully loaded into another schema.

What I'd like would be to add a feature to the Schema Extract dialog to be able to select a class, or classes then click a button to add in all required classes which are referenced for the extract to be successfully loaded into another schema.

As an example, extracting a class and loading it into another schema requires any collection classes which have members of that class to be extracted (or already present) in the target schema. Similarly references to other classes (e.g. with inverses) are also required.
  • Guest
  • May 1 2019
  • IDE Backlog
Software Medical Infomatics Limited 8/11/2017 12:10:52 PM
Brian - yes, there will be the issue of following all paths and eventually potentially including the whole schema. As you suggest being able to drill down might be a solution. I've considered generating a UNL and have used that strategy in the past, but it would be nice if Jade did this for us.

The UNL file approach would be way more useful if you could use a UNL file to populate the Selective Extract tab. That way you could try the extract and load, saving the UNL file, and if it failed but you knew what class/classes were missing you could reload the UNL file to populate the selective tab, then make further additions to the extracted classes (and then re-save the UNL file).

John - I like the idea of being able to iteratively selectively load classes until you could make it work. That would be a big bonus.

Ty - I have a current situation where I have a very old schema with lots of functionality in it that is no longer used (it's an old thin client application and the new application uses Jade only as an API), but the schema also contains a small number of classes I want to keep. My approach is to extract those classes (they're transient and have no instances) and move them to a new schema, then eventually delete the old schema. As I (and others) have experienced, it's a bit of a frustrating process that could be significantly improved.

Ty Baen-Price 7/11/2017 3:10:34 PM
Can you please elaborate more on what problem you trying to solve, and what limitations you are operating under?

If I look at the problem as stated, of moving a set of classes from schema A to schema B, then using the extract & load facilities isn't the first mechanism that springs to mind. I would want to perform this task in the IDE, and then use the extract and load facilities to transfer this schema state into other systems. I would also need a mechanism to retain instances, if appropriate.

John Beaufoy 7/11/2017 2:13:38 PM
As per suggestion below, we already have the ability to selectively extract, this would be to selectively load.

John Beaufoy 7/11/2017 2:11:09 PM
The flipside of this would be improving the tooling on scm load. So you opt for a heavier/full extract, but then have advanced options to ignore/compare/merge content on load. If the load fails due to a missing dependency, add more entities through the same ?wizard?, until such time as it loads in. I?ve found the problem is not just whether you?ve captured all the code from the source schema, its avoiding unintentionally overwriting content in the target!

Brian Johnstone 7/11/2017 10:30:35 AM
I guess part of the issue here is how far to go with this "expanding" of classes. For example, suppose you have a new ClassA which is inverse referenced with a new ClassB. Clicking that button would add ClassB, but what if the new ClassB is also inverse referenced with an existing ClassC. You would still get an error trying to load this extract unless we also include ClassC in the extract.

I suppose it could go one level out, and if you click it again it goes another 1 level out, but in a typical OO design, it would quickly mean your entire class structure would soon be included in that extract, especially when you encounter a class that has an inversed reference to your root object class.

Also, regarding your comment about "requires any collection classes to also be extracted". This isn't actually "required" unless those collection classes are used in references/inverses to related classes.

Question: In the interim, have you considered writing your own application to identify these expanded class lists such that it can generate the appropriate details in a .UNL file and then do a parameter based schema extract? This may help automate some of the effort required when trying to selectively patch model changes, or move groups of related classes between schemas. Also, once you have a UNL file, when you find an additional class is also needed it can vastly simplify the effort required to redo the extract inclusive of that one additional class by simply adding that class to the UNL file.
  • Attach files
  • +6