Consistency in derserialization of EA DB Col

[Paolo F Cantoni]

One of the main reasons I chose EA over its competitors is that it is primarily database based.

While Sparx does NOT endorse (or do they direct database manipulation, it's not to hard and over the years I've managed to do a lot of surgery on models in this way.  With the usual caveats of backing up etc - it's a viable way of working.

And it can be blindingly fast...  For example, we've mentioned analysing XMI import/export bugs.  We've built a tool to functionally compare two large models.  If we were to use the baseline compare process (which is actually not appropriate in this context)  we'd have to run it overnight.  Our process takes less than 75 secs from "go to whoa".  Admittedly, we're not checking as much as the baseline compare but certainly enough to diagnose the issues.

In performing surgery we do have a problem in that some db fields are serializations of internal data in the form:

name=value;

An example is:
ExcludeRTF=0;DocAll=0;HideQuals=0;AttPkg=1;ShowTests=0;ShowMaint=0;SuppressFOC=0;TDurLow=0;TDurHigh=100;TDurUnit=;TDurHide=0;TConnectorNotation=;TExplicitNavigability=0;

Thus for example, to (in this case) change the diagram properties to explicitly show non-navigable AssociationEnds requires changing: TExplicitNavigability=0; to TExplicitNavigability=1;

Managing this kind of change using pure SQL is problematic.

We done some experimenting and it would appear (no surprise given the way the rest of EA seems to work) that there are a number of inconsistencies...  I won't go into the details here but suffice to say that the parsing (or deserializing) of the strings varies depending upon the table and column involved.

Now we want it clearly understood that we aren't asking Sparx to endorse Database direct manipulation.  We are merely asking that EA be consistent in how it processes these columns.  

We propose that deserialization not be dependent on any particular order of name/value pairs; that it progresses from right to left and that if a name/value pair occurs more than once, the rightmost one takes precedence.  Thus in the following example:
ExcludeRTF=0;DocAll=0;TExplicitNavigability=1;HideQuals=0;AttPkg=1;ShowTests=0;ShowMaint=0;SuppressFOC=0;TDurLow=0;TDurHigh=100;TDurUnit=;TDurHide=0;TConnectorNotation=;TExplicitNavigability=0;

TExplicitNavigability=0; is the outcome (the 0 replacing the previous 1).

This would ensure consistency in processing these serialization columns.

Thoughts? Votes?

Paolo

[size=0]©2007 Paolo Cantoni & Darren Sampson, Ripple Systems[/size]

[sargasso]

Absolutely!!!

I have been writing ¨add-outs¨ for two years.  As you say its the quickest way to
a) resolve EA outstanding issues (does the phase ¨multiple select"jog any memories)
b) expand the utility of EA in a specific functional area (like test management or issue management or just plain extended reporting).

While using the tlb and the object model is a more stable and defendable approach, I frequently hack something together using C# or even Ms-Access directly using the db or rather more infrequently updating the db ( eg reset the default diagram...).  As you say, hacking around with the serialised field contents is rather painful.

bruce  

[«Midnight»]

Completely agree.

That said, I've mentioned many times that (entirely IMHO) things seem to be approaching the point where another schema change would be reasonable. One thing that this might do is reduce the number of these name-value pairs by moving some (many?) into tables or relations (as the case might be) of their own (i.e. normalizing these portions of the model).

I say this with truly mixed feelings, as it is truly a two-edged sword. Still, best to get the topic out into the clear light of day...

David