From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f70e7a457bf23e69 X-Google-Attributes: gid103376,public From: mjmeie@ss5.magec.com (Mike Meier) Subject: Re: Optimizing and Constraint Checks Date: 1995/03/30 Message-ID: #1/1 X-Deja-AN: 100540659 sender: usenet@ss3.magec.com references: <3kv990$o7d@butch.lmsc.lockheed.com> <3l3l2v$ria@gnat.cs.nyu.edu> organization: Magnavox Electronics Systems Company newsgroups: comp.lang.ada Date: 1995-03-30T00:00:00+00:00 List-Id: Ed Bruce (edward@igate1.hac.com) wrote: : Which leads to an increased risk of making a mistake that won't be caught : easily if at all. That is if the an enumerated_value'POS is currently 5 in : the database and should be changed to 4 (a literal was deleted), but is : changed to 3. Well enumeration_type'VAL(3) is this case is legal but : invalid. : So I have suggested to the principal engineers on our project that we use : enumeration representation clauses and unchecked type conversion. We faced the same problems on our rather large (1M SLOC) project with lots of enumerated types in the DB. It turns out that even rep clauses and unchecked type conversions have potential for maintainability and portability problems. Our solution was to require the definition and use of a set of mapping functions (for which we provided a generic) for every enumerated type to be stored in the DB. This may seem like overkill, but it saved significant effort overall the (so far) 5-year life of the project. Additional benefits were that the values used in the DB could be used in many other contexts, and that the values could be defined in the body rather than the spec (which reduced recompilation when a value had to be changed).