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 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-17 06:30:31 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!wn13feed!wn11feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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> <3F8F2D7B.6060307@comcast.net> In-Reply-To: <3F8F2D7B.6060307@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 17 Oct 2003 09:15:41 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1066396517 198.96.223.163 (Fri, 17 Oct 2003 09:15:17 EDT) NNTP-Posting-Date: Fri, 17 Oct 2003 09:15:17 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:1072 Date: 2003-10-17T09:15:41-04:00 List-Id: Robert I. Eachus wrote: > 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. ;-) I'll agree that you can find exceptions to any "normal". But even in this particular case, you might just load a drop down or list box in a GUI (one row at a time), and let the user choose the correct one. I mean, is the program going to say "select the oldest person, because the younger person is less likely to need drugs?" I doubt it ;-) Even if you have such a process, then you would use a ORDER BY clause, and accept the first row. >> 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? I am not confused at all. What you have just admitted is that you equate an empty string to a NULL column value, which is not quite the same thing! Why are they different? Well, for some applications an empty string "" says, that I have explicitly stated that I have defined its contents as empty (ie. there is "no comment" for example, when the column might represent a description/comment). NULL OTOH, indicates that the value is not defined ("a comment is not yet defined", for example), or that there is no value for it ("no comment is possible/applicable", for example). Your package doesn't allow the programmer to make that distinction, which, for me is a show stopper. Now, before you jump all over that, I am aware that _some_ databases don't make that distinction well, or in some cases, not at all. Sybase makes them equivalent in their ctlib client library, much to my disappointment. However, I do believe that their stored procedure code will see the values as being "different" (unconfirmed). In other cases, the distinction is made in some APIs, for the same database, but not in others API/API-modes. For example, using Informix embedded SQL/C, you can work without null indicators (a separate int variable) or with them. When using the null indicator, you _can_ make that fine distinction. When choosing _not_ to use Informix null indicator host variable, you have to rely on the empty string idea, which can only tell you that the string is empty (you can assume NULL if you want to, but it may not accurately reflect the column value). In this case, you have to use the string value ' ' to represent an empty string. The distinction however, remains _VERY REAL_ on the database server side! Try pretending that they are the same in the stored procedure code, and things will blow up on you ;-) Your applications may never care about that distinction, and that is fine if it works for you. But my point is that your package does not "properly" make the NULL distinction. > 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. But you have not sold the idea why an array for the first example is any better. All you have demonstrated is that "it works". The first example does not necessarily require processing the rows in a "batch". You could : - spit them out to a web server connection one row at a time - load them into a GUI control one row at a time - pump them out to a report one row at a time Even your earlier example, represents a situation where that information is likely to be presented to a human operator to choose. Given that, that information is just as likely to be loaded into a drop down/list box one row at a time. In _most_ cases, I see no need for this type of "batching" of rows (emphasis on the "most") ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg