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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-16 16:45:14 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3F8F2D7B.6060307@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A nongeneric bounded string array type (in database code) References: <3F7AC5B0.9080108@noplace.com> <3F7B7641.9030908@noplace.com> <3F7C8482.20102@comcast.net> <3F7D69EA.5030707@noplace.com> <3F7E2740.1050703@comcast.net> <3F7EBD85.8080205@noplace.com> <3F819C99.6080904@cogeco.ca> <3F844FE9.7030500@comcast.net> <3F86EEE3.4030600@comcast.net> <3F8EAF65.2030305@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1066347913 24.34.139.183 (Thu, 16 Oct 2003 23:45:13 GMT) NNTP-Posting-Date: Thu, 16 Oct 2003 23:45:13 GMT Organization: Comcast Online Date: Thu, 16 Oct 2003 23:45:13 GMT Xref: archiver1.google.com comp.lang.ada:1027 Date: 2003-10-16T23:45:13+00:00 List-Id: Warren W. Gay VE3WWG wrote: > Using a fetch loop that processes one row at a time is so > much easier (at least when possible). This eliminates the resource > issue. The CLIENT LIBRARY should already be handling the EFFICIENCY > aspects of fetching, in bunches of rows, thus freeing your code > from such implementation details. > > If you insist on arrays at a time processing, then you > are usually focusing on efficiency, which is very implementation > minded design. This is what many Ada people try to get > away from (and certainly my focus). No, there are queries where the normal case is one matching record, and discriminating between two (or more) records is an extra step. When I go to the drug store, they check my date of birth because they also have records for my son. (The same thing happens at the HMO, but they usually figure it out without asking me if I was born in 1946 or 1982. ;-) > As a side note, your Ada_Strings_Bounded_Array package makes a > common mistake: it does not allow for the processing of NULL > values. This is one fault I see so frequently in embedded SQL > code, because the programmer never took the trouble to code > for that possibility. This leads to all sorts of hideous > problems when NULLs are encountered in processing. There is > no doubt that Ada_Strings_Bounded_Array could be augmented > to handle this, but does illustrate how this RDBMS feature > gets overlooked. Microsoft is another one that is guilty of > this in their database controls (try handling a null date > type in the date picker, for example ;-) You are confused. The Ada_Strings_Bounded_Array package allows for null strings in any row, and an array with no rows. (Or both. ;-) Was there some other type of NULL value I should allow for? > If you take arrays to the further level of columns x rows, then > you have a 2-dimensional array to mess with -- which in my view > is very dangerous from a code readability/code-write-reliability > point of view. Don't get me wrong, arrays have their place. No, as far as I am concerned, it handles perfectly the case where you expect a "few" matches, for some version of few. As you say, for cases where you expect many matches, an iteration scheme is better, and if zero or one matches, a string is fine. Let me use the registry for Ada packages that I have been proposing as an example. If I did a search for packages named ODBC, that would be a good case for the "few" type query. A query for all database packages would best be handled by returning an iterator of some sort. A programmer can decide on the best query for his particular purpose. -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig