Inconsistencies in Repository technologies

[Paolo F Cantoni]

We are moving into the arena of having multiple repositories in multiple technologies (.EAP, MS SQL Server, Oracle).  So we started to investigate the compatibilities and found (not really to our surprise) that the various structures for the different technologies were inconsistent.  Not merely because of technological differences (for example Oracle hasn't had Booleans since forever), but just plain bugs.  Column is 50 in one technology, 255 in another etc...  This affects the ability to generate the correct outcomes with the Tools|Data Management>Project Transfer... functionality.

Now, as far as we can ascertain, EA code emits "0" and "1" for (conceptually) Boolean columns.  Since there is no consistency, even within a row, let alone a technology, on how Booleans are represented it can create issues if you query the repository directly (as mentioned in: NULL is NOT False).

So it was interesting to observe that although the t_package.IsControlled field is a Number (int) EA still attempts to query it as though it were a Boolean Yes/No field in the .EAP (the query probably includes IsControlled = True) but NOT (apparently) in MS SQL Server.

Don't ask how we know - that's "Secret Data Architect's business..."

The reason for reporting the bug is (as usual) the consistency one...  Why is only this column in the table (where there are at least three other Booleans) treated this way?  In fact, we know there's probably one or two others that behave the same way across the DB (now that we've sussed out what - we think - is going on).

Writing code with all these exceptions and conditionals leads to buggy and inconsistent behaviour.  Since EA is Emitting "0" and "1" for the Boolean values (presumably because of differences in technologies), it should explicitly test for "0" and "1" in all technologies.  It's just bad coding (if not bad design)...

Naturally, the discovery of this "bug" reduces our ability to create consistent outcomes in all the technologies of interest.

Thoughts?
Reported,
Paolo

[Paolo F Cantoni]

When you perform a Tools|Import Reference Data..., the XML processor will write out: "FALSE" not "0" like the rest of EA.

Paolo

[Paolo F Cantoni]

By technologies, I ALSO Mean the API!

If you hide a line using the GUI EA writes a "1" in t_diagramlinks.Hidden!  If you use the Automation interface, EA writes "-1"

I do hope all this stuff will be fixed up for v8!

Paolo

[beginner]

I still wonder how you keep up your optimism over so many years.

b.

[Paolo F Cantoni]

I still wonder how you keep up your optimism over so many years.

b.

Well it seems to have done wonders for my "black box" diagnostic skills.  

Paolo

[beginner]

You mean "black box" as sort of black magic paired with an MS access application?

b.

[Paolo F Cantoni]

By technologies, I ALSO Mean the API!
[size=18]...[/size]

And I also mean MDG technologies...

Drag a Component Metaclass onto the diagram and it comes complete with:

+IsDirectlyInstantiated:  Boolean = true

drag a Node Metaclass onto the diagram and it says...

+IsExecutionEnvironment:  boolean = false

Since today most languages are case sensitive; is a Boolean a boolean or not?

Anybody want to make book on all this stuff being fixed up for v8?

Reported,
Paolo

[fwoolz]

Paolo,

100:1 says it ain't fixed by v10...

The starting point for all refactoring of the EA code base, Grasshopper, is the #$^@*~! schema. Until it has been made consistent, all patching is as the sound of one hand clapping. Or a tree falling in the ocean. Or something like that.

Seriously, until Sparx bites the bullet and completely revamps the EA database schema so that booleans are always booleans (or short ints, or whatever makes it easiest to work with multiple RDBMS engines), etc., and primary keys in related tables are consistent (in some cases it's the Object ID, in others the GUID), etc. etc., and hacked fields get factored out into their own tables, etc. etc. etc. so help me Codd, we will always have bugs to keep us occupied and amused (or bemused). That's the price we pay (development-wise) yet don't pay ($$$-wise) for using EA.

I, like beginner, do admire and appreciate your persistence, even if the Sparxians sometimes do not. They, likewise, deserve kudos for keeping EA affordable yet powerful. Besides, these bugs may be all that lie between Sparx and World Domination^TM!

Cheers,
Fred

PS: Here come the nice men in the white coats...

[Paolo F Cantoni]

Paolo,

100:1 says it ain't fixed by v10...

I'll not take you up on that...

The starting point for all refactoring of the EA code base, Grasshopper, is the #$^@*~! schema. Until it has been made consistent, all patching is as the sound of one hand clapping. Or a tree falling in the ocean. Or something like that.

In "the best of all possible worlds" that's so...  But in my experience, any improvement in consistency is like a seed crystal - it grows..  If the Sparxians "weeded" EA for inconsistencies, I'm sure they'd find life easier.  Over time, increasingly so - they would then have resources available to tackle the big "ones" (see below)

Seriously, until Sparx bites the bullet and completely revamps the EA database schema so that booleans are always booleans (or short ints, or whatever makes it easiest to work with multiple RDBMS engines), etc., and primary keys in related tables are consistent (in some cases it's the Object ID, in others the GUID), etc. etc., and hacked fields get factored out into their own tables, etc. etc. etc. so help me Codd, we will always have bugs to keep us occupied and amused (or bemused). That's the price we pay (development-wise) yet don't pay ($$$-wise) for using EA.

Still a price...  In my case, it cost me more than a more expensive product.

I, like beginner, do admire and appreciate your persistence, even if the Sparxians sometimes do not.

Thanks for that Fred, appreciate it.  In the end persistence is the only thing that matters.

They, likewise, deserve kudos for keeping EA affordable yet powerful. Besides, these bugs may be all that lie between Sparx and World Domination^TM!
[size=18]...[/size]

Yes, I get that feeling also...  But like I've often said (and you're implying above), they can't get close to World Domination without some serious redesign.
I'm sure there's a schema design that can effectively balance the need for referential integrity and flexibility, without the need for so many hacked fields...

Paolo

[fwoolz]

In "the best of all possible worlds" that's so...  But in my experience, any improvement in consistency is like a seed crystal - it grows..  If the Sparxians "weeded" EA for inconsistencies, I'm sure they'd find life easier.  Over time, increasingly so - they would then have resources available to tackle the big "ones" (see below)

I must say I agree, what I wrote previously notwithstanding. There IS an incremental path to a better EA, but it requires that Sparx take a breather from time to time to do some serious weeding, as you put it, rather than piling new features, useful though they may be, on top of the weeds. As I've suggested before, Sparx may find that opening the code base up a wee bit to user collaboration, allowing users to help with the weeding, may pave the way to global conquest.

Cheers,
Fred

[KP]

By technologies, I ALSO Mean the API!
[size=18]...[/size]

And I also mean MDG technologies...

Drag a Component Metaclass onto the diagram and it comes complete with:

+IsDirectlyInstantiated:  Boolean = true

drag a Node Metaclass onto the diagram and it says...

+IsExecutionEnvironment:  boolean = false

Nothing to do with technologies, it's a typo in EA's internal UML metamodel, easily fixed. In the meantime, you may edit the attribute and change its type: in UML, the correct names are Boolean, true and false.

[fwoolz]

Another typo, this one from the so-called "Wicked Bible" and a bit more famous (or shall I say infamous):

Exodus 20:14 Thou shalt commit adultery.

A single typo can change the world...

Which is to say, thou shalt not minimize valid criticisms of a software product by focusing on an easily swatted (and therefore easily dismissed) bug when it is only one of a swarm of bugs, not all of which are so easily swatted. As one who has done a fair bit of poking around the innards of EA (not nearly as much, I confess, as some), I sympathize with Paolo's quest for consistency. As much as Sparxians may tire of hearing about it, it can only serve to make the product better in the long run.

Cheers,
Fred

[beginner]

Well spoken Fred. However, Neil is "just" in the support team (brave guy!) not one of the developer gods. Not speaking of the marketing department (make profit!). I gave up hope a long time ago. It's just like in Dante's Inferno. We're approaching the inner circles...

b.

[Paolo F Cantoni]

Well spoken Fred. However, Neil is "just" in the support team (brave guy!) not one of the developer gods. Not speaking of the marketing department (make profit!). I gave up hope a long time ago. It's just like in Dante's Inferno. We're approaching the inner circles...

b.

Hi b.

How do you know that? (That Neil is (just/only) in the support team)

Paolo

[beginner]

Just guessed from the facts that he writes posts here in the forum (bet that none of the programmers even know this exists) and that I received mails sent as being from the support team (last from Jan 2009).

I once worked in a support team for a year and I highly appreciate Neil's work (besides yours of course). It's usually not a nice place between customers and developers.

b.