Author Topic: Wish: Transformations, code generation and changes  (Read 2625 times)

Thomas_Arnbjerg

  • EA User
  • **
  • Posts: 80
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Wish: Transformations, code generation and changes
« on: September 17, 2007, 09:55:44 pm »
It would be nice if packages generated by transformations or from which code is generated are marked as "outdated" or "code needs to be regenerated", when changes are done to the source package.

Example, which just cost me 3 hours:

I've made a class diagram with persisted classes. I apply the built-in DDL transformation and generate the db-creation SQL script (DDL). I've also implemented code generation templates to automate the DB I/O.
Recently I changed the data type of an attribute, applied the  DDL transformation but forgot to re-generate the SQL script. The result was a number of errors in the auto generated code, which puzzled me for some time.

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: Wish: Transformations, code generation and cha
« Reply #1 on: September 18, 2007, 01:56:13 am »
Thomas,

How about going a little farther on this.

Perhaps we could link this to changing the version attribute on the package, element, and perhaps the diagram.

Of course, this would require some kind of version number template, but that could easily be done along the same general lines as the autonumber feature built into EA elsewhere.

What say?

David
No, you can't have it!

Thomas_Arnbjerg

  • EA User
  • **
  • Posts: 80
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: Wish: Transformations, code generation and cha
« Reply #2 on: September 18, 2007, 02:52:27 am »
Excellent idea.

Tracking changes in general is an important issue. It would also be nice to link versions of the templates to the model elements/source code:
1) If MDA transforms/code generation is done massively a sanity check could be done by comparing the current version number of a template with the version number of the template, which generated a model element.
2) I could write the template version into source code and verify that all source code is generated by the proper version of a template.

I have another future version issue I'll have to think about. Right now we might ship code generated from one set of templates. In the next version the templates have most likely changed a bit. I will then have to identify the template delta to identify potential compatibility problems. I haven't yet figured out how to do this. Ideally I would like to do a diff on the two template sets. As a supplement/alternative it could be useful to extract a list of template version numbers and simply look for changes. That would at least tell me where to look for problems.