Sparx Systems Forum

Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Uffe on May 18, 2020, 07:00:17 pm

Title: Why, oh Why
Post by: Uffe on May 18, 2020, 07:00:17 pm
Hey people,


Does anyone know why, in the MDG Technology XML format, automation scripts are encoded as binary data?
It makes it that much harder to track changes.

They're stored as plain text in the database (I *think*, but then I've only checked that with EA's built-in SQL scratch pad which has a sprinkling of magic in it), and they're exported as plainish text in the reference data XML format.

In addition, there's precious little space to be saved by binaryizing data that needs to be unpacked and passed as text to a scripting engine. Pretty sure the amount of memory saved turns out to be negative for any script that actually gets used.

So - huh?


/Uffe
Title: Re: Why, oh Why
Post by: Geert Bellekens on May 18, 2020, 07:42:58 pm
I agree, there seems little to no sense in storing scripts as binaries in MDG's.

It also goes against the general flow where an MDG is not much more as a stitched together set of reference data exports.
(it might even work if put those scripts in manually as they are in the refdata export)

I can confirm they are stored in plain text in the database.

Geert
Title: Re: Why, oh Why
Post by: Uffe on May 18, 2020, 09:16:04 pm
(it might even work if put those scripts in manually as they are in the refdata export)
Doesn't look like it.

I tried to push the reference-format data into a <Content dt:dt="string"> tag, but EA didn't accept it.
It didn't complain about the technology as a whole, which it does if the XML is broken, and I could see my test script in the Scripting window, but when I opened it the editor there was no code in it.

I didn't try removing the &#xA; escape sequences, and there might be other ways to tweak the XML to force EA to accept it. But there might not be -- EA might simply ignore the <Content> if it isn't in bin.base64.

/Uffe
Title: Re: Why, oh Why
Post by: Paolo F Cantoni on May 18, 2020, 09:17:55 pm
I agree, there seems little to no sense in storing scripts as binaries in MDG's.

It also goes against the general flow where an MDG is not much more as a stitched together set of reference data exports.
(it might even work if put those scripts in manually as they are in the refdata export)

I can confirm they are stored in plain text in the database.

Geert
Wot 'e sed!

Paolo
Title: Re: Why, oh Why
Post by: Geert Bellekens on May 18, 2020, 10:14:52 pm
(it might even work if put those scripts in manually as they are in the refdata export)
Doesn't look like it.
Too bad, was worth a try though. :-\

Geert
Title: Re: Why, oh Why
Post by: Sunshine on May 19, 2020, 06:11:50 am
The only reason I can guess is they put the scripts in as binary as they didn't want people modifying them. As there is no checksum or digital signature to check modification it could have been that putting it in binary is light-hearted way of protecting the MDG scripts. Dunno for sure though