Null is NOT False

[Paolo F Cantoni]

When EA does a package import it replaces a false value in t_attribute.IsStatic with a NULL value.

NULL Is NOT the same as False!

Of ALL the Booleans in t_attribute, IsStatic is the only one that exhibits this behaviour.

This needs to be rectified immediately,  the semantics of the model are changed on import.

Indeed, you should check that ALL booleans ONLY emit 0 & 1.

Steps:
Take a repository,  ensure there are NO t_attribute rows with IsStatic = NULL.  Make sure there ARE t_attribute Rows with IsStatic = 0

Export then re-import.

Observe IsStatic now contains NULL values for the rows that were previously 0.
Reported,
Paolo

[Paolo F Cantoni]

The bug as reported previously is NOT quite correct – it’s actually an export problem.  A Zero value placed in the IsStatic column will NOT generate an expected IsStatic=”false” entry for the attribute in the exported XML.  Instead, it generates NO entry at all – which is (correctly) interpreted in import as a NULL.   This is erroneous!

Bug Report Updated to Sparx.
Paolo

[Paolo F Cantoni]

Related to this problem is that various add-ins will insert NULLs for false (instead of zero as the UI does).

I've had some feedback from Sparx that suggests this is more pervasive that I first thought.  It would seem (and my understanding may be clouded)  that the API and the UI produce different results (as one would expect from an inconsistently incorrect system) and they differ inconsistently...  Some (very few) Boolean columns will be emitted with NULL for false, while the others aren't.

Sparx have replied:
Whether this database value contains "0" or "" has no negative effect on EA's actual behavior in relation to this property that we can find.  EA simply interprets these field types as FALSE where the value is not equal to "1".  How you interact with this field when querying directly via the database is entirely your own responsibility.

To which I replied that the semantics of NULL and false are NOT the same (and that "" is NOT NULL - which is what is emitted).  But my bug is the inconsistency one.  Why should some Boolean columns work consistently and other not?

I also ventured the opinion that the IP invested by a user in the model is NOT EA's behaviour but the data itself.  Consequently, we users expect that the data in a column should be consistent.

Thoughts?
Paolo

[Geert Bellekens]

I agree with Paolo.
If I export and then import a (part of) a model then I expect the data to be "exactly" the same.
If we would never need to query the database directly then I would agree with Sparx, that it's none of our business, but that isn't the case.

The API COM object is just too slow to process high volumes, wich forces me to use the Repository.SQLQuery feature.

EA has a build-in SQL Search definition functionality which exposes users to the database (and its inconsistencies) as well.

Come-on, this can't be too hard to fix can it?

Geert

[Makulik]

I also agree with Paolo and Geert. As far these tables and columns are visible through various interfaces of EA (API, SQL-query, UI) they should provide consistent information for all of them. Especially Geerts point about the SQL queries is important to consider, SQL definitiely doesn't consider NULL and false in a boolean column to be the same. The affected rows (with NULL values) might not appear in query results that use these columns as filter in  a WHERE clause, without doing something extra, to convert NULLed columns to false. How should one know??

WBR
Günther

[fwoolz]

Hear, hear... NULL is the bugbear of programmers and database developers alike, causing untold grief. One of these days a null reference is gonna launch some ICBMs by accident...

IMHO, changing non-null values to NULL (and vice-versa) is a major problem, regardless of import-export direction, that needs to be fixed post haste. EA may be bulletproof in this area, but (applying the immortal words of Sean Connery as Captain Marko Ramius) most of the rest of the world doesn't "react well to bullets."

Fred Woolsey

[g.makulik]

Right said fred!

[son-of-sargasso]

I wholeheartedly agree with Paolo (&tc).  I have seen this problem both in EA and elsewhere where coders have just been too lazy to follow through on tristate booleans.

In Paolo's case this is (IMO) a major problem.  Disregarding re-import for the minute, if an export is replacing specific FALSE values with null (or null interpreted by value omission) the the export interface, to an external viewer is just plainly and simply WRONG. Not only from the programmer's viewpoint but from the user's view as well.

An export interface that delivers incorrect data is equivalent to having no interface at all.

bruce