Design Decisions in the Translator

Orthogonal APIs: Rethinking Present but Null

One of the design mistakes in Chameleon was the way there was bleed over in the table APIs of HL7 concepts which really had no place being there.

In the HL7 standard there is a somewhat ill defined and inconsistently implemented concept of that if you see a field with |””| in it that it means that field is defined in the feed, but it is NULL. This is opposed to || which mean field might either be:

  • Not implemented.
  • Not changed.

At some point in an effort to be helpful a patch was introduced into Chameleon that used the python None value to represent some of these concepts, see: Null, Empty and Invalid Values.

The problem is that it means that:

  • The API has become complicated.
  • It makes too many assumptions about the given feed which are likely to be wrong, the interface programmer implementing the feed is in a much better position to know what |””| and || really mean with the context of this feed.
  • There is bleed over of HL7 concepts going into what should be a database API.

Finding simple solutions is a lot harder than slapping together complex ones and in the first prototype of the table API in the Translator some of these bad choices were being ported over. See my joke about the pot roast. This stuff always smelled wrong to me. After much discussion and thought we came up with a much simpler more logical solution.

Basically we added an API to the table object that would allow the interface programmer to explicitly remove a column from a record that was to be inserted into the database, like this:


This makes the choices very explicit and clear and 100% under the control of person who really understands the interface, the interface programmer actually writing the interface.

See handling non-present and NULL data with databases.

Next: C Level Perspective on the Translator

Leave A Comment?