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: l107353@cliffy.lfwc.lockheed.com (Garlington KE) Subject: Re: Optimizing and Constraint Checks Date: 1995/03/29 Message-ID: <3lcl6m$bhd@butch.lmsc.lockheed.com>#1/1 X-Deja-AN: 100540717 references: <3kv990$o7d@butch.lmsc.lockheed.com> <3l3l2v$ria@gnat.cs.nyu.edu> organization: Lockheed Missiles and Space Co. newsgroups: comp.lang.ada Date: 1995-03-29T00:00:00+00:00 List-Id: Ed Bruce (edward@igate1.hac.com) wrote: : The underlining problem is how to represent enumeration types in an : external database(that is one not implemented directly in Ada). Without thinking about it very hard, my first impulse is to use a cross- reference table of the Ada enumeration type values and the values used in the database, and then bury this table in an appropriate encapsulation. This way, you should be able to represent the enumeration values as strings, or numbers, or whatever in the database. If the enumeration type changes, and you code the aggregate for the cross-reference table properly, you should be able to control changes fairly well. I'm not exactly sure what you want done if an enueration value is replaced; for example, if the third value changes from BLUE to YELLOW. You may want to encode a version number somewhere in the database and in the encapsulation, and have it check on elaboration (or some appropriate point). This should work in Ada-anything. -------------------------------------------------------------------- Ken Garlington GarlingtonKE@lfwc.lockheed.com F-22 Computer Resources Lockheed Fort Worth Co. If LFWC or the F-22 program has any opinions, they aren't telling me.