From lechner@cs.uml.edu Thu Nov 16 02:34:18 2006 From: Bob Lechner Subject: Re: Test Implementation, integration with sample DB, future auto-generation. To: cguffey@gmail.com (Chris Guffey) Cc:all RJLRef: $PH/06f522/asgnt3/CKtesting.vs.validation.txt (was auto_generatedCKtests061116.txt) > From cguffey@gmail.com Thu Nov 16 00:04:12 2006 > Date: Thu, 16 Nov 2006 00:03:57 -0500 > From: "Chris Guffey" > To: "Bob Lechner" > Subject: Re: Test Implementation, integration with sample DB, future auto-generation. > Cc: "Anthony J Gabrielson" , alison_lea@yahoo.com, > kbagley@us.ibm.com, nitin.sonawane@verizon.net, > "Nitin Sonawane" , nitin.sonawane@gmail.com > > It would not be difficult to modify keyExists to return the number of > matched records. It's probably 30 minutes worth of work to do. The > only downside is that it'll have to loop through every row in the XX > table so it'll will take longer depending on the table size. An > optional max_matches count could be added as input though to make it > stop once records_found == max_matches ... all in all that last part > is probably overkill but it could save time if you only want to know > IF there are matches as opposed to how many there are. > [RJL: That's not required - a more general solution would probably be auto-generated anyway. This is a good time to point out how SQL can avoid such brute-force searches even tho it must return a list of retrieved and rebuilt records, by merging fields selected from multiple related tables whose fkeys match. Chgen links table-rows (XXcurr->next) in pkey-sorted order. Therefore it would be easy to auto-generate btrees or hash tables on the pkey (an unsigned int). In fact, chgen will generate a Btree index on any pkey if tbl is tagged (in a very hacked way) in .sch. For queries on [subsets of] composite key components it is more efficient to exploit the container hierachy in the ERD (represented exactly by TA-rows that are fkeys). E.g., to find 91.522.291, a program reflecting on metadata can discover the DE-->CO-->CT hierarchy, then it knows that DE should be searched first, CO next and CT last. One search thru 2K sections is replacd by 3 smaller ones: search 50 DEs then 50 COs then 2 CTs. The cost is 50+50+2, not 2K comparisons. RJL > > > On 11/15/06, Bob Lechner wrote: > > RJLRef: $PH/06f522/asgnt3/auto_generatedCKtests061115.txt > > > > I agree with AG that two clients each with PASS/FAIL > > examples call keyExists enough ways. I don't really expect > > a full pr_add test to be in the test driver. > > > > The other required variants are the three ftypes > > (hcg_key, string and int). It is important to test > > cases where 2 or 3 of these exist in the same fvalue list. > > > > I agree in principle that a ptr would be more convenient, > > but in retrospect a count (0,1,>1) would have been better: > > > > keyExists can't just return a ptr if there can be > > more than one matching record (e.g. if fieldlist is an > > incomplete [non-]key which it might be in more general > > queries). In this case it would return the FIRST matching > > row - but how would it report there might be more than one?. > > > > BTWay, bde has this problem when selecting a drawing component. > > How to show which one is selectred (highlight it) > > so the user can confirm the selection or select another.. > > Then how to select another one, which might be hidden underneath? > > (move the mouse; last resort: move the one that got in the way.) > > Class-specific menu radio buttons also help by restricting > > each selection to one type of object. > > > > Regression testing gives an advantage to collecting > > instances of CQ's into their own database: the driver can > > pr_load and table_loop thru them to execute unit tets. > > The desired results are dependent on the sample > > database as well as the CQ list so they don't belong > > in table CQ ubnless it is part of the same versioned database. > > > > In the long run, I might auto-generate in pr_load.c calls to > > keyExists for EVERY CK child of a TT that picks its fvalues > > ont of each record that is pr_loaded from the SISRev061014.dat > > sample database. The database then becomes the CQ_list. > > > > Bob Lechner > > ... >