BUG: Column deletion broken

[Paolo F Cantoni]

EA when in Data Modelling mode, enforces relationships between attributes and operations (as it should).

However this functionality is broken!

If you delete a column, it is only deleted from the operation parameter list.  The operation itself is NOT deleted (if the column is one of a compound set).  The semantics of the operation ARE however - destroyed!  

On other than planet Sparx, the normal user interaction (in this type of situation) is:  
"This column is part of a compound constraint, do you want to delete the constraint or just delete the column from the constraint".

This way, the user controls the variation in semantics.

Paolo

[size=10]Using EA in spite of EA, NOT because of it![/size] ^TM[/color]

BTW: we keep a score here on how long after I report a bug I find the next one - this one is the new champion - 37 secs!

[«Midnight»]

...If you delete a column, it is only deleted from the operation parameter list.  The operation itself is NOT deleted (if the column is one of a compound set).  The semantics of the operation ARE however - destroyed!...

Do you mean that EA does it this way, or that it should?

David

[Paolo F Cantoni]

Do you mean that EA does it this way, or that it should?

David

David,

EA doesn't prompt... It should.  It just silently removes the column from the operation.

Paolo

[«Midnight»]

Somehow I was hoping this was not the case.

I can see how it comes up though. If it were a class , you'd probably destroy the semantics of the operation when the attribute was changed.

However, in a DBMS the parallel breaks down. It is reasonable to remove a column (from a constraint or from the table), yet have the rest of the constraint remain valid. This starts getting really significant when the table is being round tripped, since there can be all kinds of additional information tacked onto the constraint.

This is YA side effect of 'bending' class operations to capture indexes. Sparx is not the author of this problem, having inherited it with rest of the old (draft) Rational/IBM "profile."

I need to borrow your soap box for a moment Paolo.

Since the IMM (or whatever it's called next time it sees the light of day) proposal at OMG appears indefinitely stalled, we need to do some serious work now to get EA's data modeling capability up to snuff. Later, when (if) IMM decides to reveal itself, and if it lives up to (much) earlier promises to cover data structures, we can address some future paradigm.

For the nonce we're stuck in the current quagmire. If we're going to live in it, let's get it cleaned up!

Thanks Paolo, you can have the box back now.

David

[Paolo F Cantoni]

David,

I think the problem is not so much in holding the constraint information in operations but in exposing them as such.

Sparx have learned somewhat with their mechanisms for XML Schemas.  The implementation is inconsistent (of course  )  But the idea is perfectly valid.

You could quite easily impose an Data Modelling specific UI over the top of the underlying structures.  For example, if you take a look at Embarcadero ER/Studio's approach to managing these concepts, it's much more aligned with the DM domain.  You could place a similar UI over the top of the current implementation.

Paolo

[«Midnight»]

For that matter the current (with a few repairs that are required anyway) EA MDG Technology paradigm could be used.

Regardless, separation of database models from the UML logical model back end (as seen in EA) has to occur. Sooner is better, since there's going to be rework of the entire implemented feature set when this finally happens.

David

[Paolo F Cantoni]

For that matter the current (with a few repairs that are required anyway) EA MDG Technology paradigm could be used.

Regardless, separation of database models from the UML logical model back end (as seen in EA) has to occur. Sooner is better, since there's going to be rework of the entire implemented feature set when this finally happens.

David

David,

As I'm sure you know, I've been advocating creating database modelling items first class members of their respective metatypes:
Table, Views etc as Classifier types, Columns, Keys and Indexes etc as Feature types and so.  You can still maintain the internal structure for the present, but prepare the way (as you say) for when they need to be more radically overhauled..

My AU$0.05   (BTW: the AU$ reached over US$0.92 last week!)

Paolo

[«Midnight»]

David,

As I'm sure you know, I've been advocating creating database modelling items first class members of their respective metatypes:
Table, Views etc as Classifier types, Columns, Keys and Indexes etc as Feature types and so.  You can still maintain the internal structure for the present, but prepare the way (as you say) for when they need to be more radically overhauled..

My AU$0.05   (BTW: the AU$ reached over US$0.92 last week!)

Paolo

I'm all for it Paolo!

And, as I write this CAD = 1.0526 USD. Lo, how the mighty have fallen!