From sentto-18866558-46-1161581892-lechner=cs.uml.edu@returns.groups.yahoo.com Mon Oct 23 01:22:25 2006 Subject: [UML_CS522_f2006_OOA] Re: Do we really need a CQ tabla - more infoe Reply-To: UML_CS522_f2006_OOA@yahoogroups.com RJLRef: $PH/06f523/asgnt3/CKvsCQdiffs061022.txt THis is a more detailed response to Nitin's and Chris' question. As I said earlier, table CQ is NOT necessary. However this question from Nitin confuses me: > - would the CQ table also contain values? because (to me) CQ is real data; a query test instance (CKname + field value string). not metadata like a candidate key spec: (CK plus its CA-children). If CQ did not contain values, then how could it be [unit test input data for] a query? The OPTIONAL part of such a query (instance) would be the fieldNAME list. (It is mandatory only in naive XML.) But I am not sure what Nitin means by 'string representation of candidate keys': (query test instances, or specs? field Values or field Names?). I suppose it depends on a prior assumption about what CQ means. FNames are already present in the CK---->CA aggregate after pr_loading (pr_parse-ing) the CK input specifications. CQ (instance) strings with a list (repeating group) of field values are analogous to CK-specs with multiple fnames, from which your code can derive one CK-row plus multiple CA-child rows. I had hoped you would see the analogy and reuse [the same] pr_add/pr_parse/pr_link methods for tables CK, CA and CQ. [For each CandidateKey to fieldnamelist aggregation there is an analogous CT--->CV test instance to field values aggregation, where CQ contains the CKname and TTid fields for CT plus the list of field values to populate its CV children. Pr_loading CK--->CA SPEC content is justified by its stability as metadata and reusability as GU methods. Code for keyExists methods can be based on this metadata, (either as hand-written or auto-generated code for compilation, or as [meta-]data for which you write a generic table-driven interpreter like LCP. Pr_loading all CQ--->CV unit TEST data can not be justified for asgnt3 because it is not convenient or cost-effective. Regression Test Database: ------------------------ However, automated regression testing requires a database of test cases (inputs paired with expected outcomes). Regrssion tests are repeated after each build, to verify that earlier successful tests do not now fail, or to isolate a new bug to the latest code change. This test database grows because new unit test cases are added to keep pace to the growing functionality of the code base. That was my point in giving you a heads-up. Pr_load.c code reuse: ---------------------- Freading one CQ-row to a buffer and splitting it up is what's inside the existing pr_load/load_data read loop: For each CQ-row, pr_parse converts the ASCII field values to a row-instance of type struct CV Pr_link is not needed to link CQ into existing SIS tables. (Pr_link could associate CQ input data with expected output data table QR (Query Result). If some tests have no QR-specifiable results, CQ would be 1..1 to 0..1 related to QR. More general tests could return matching row-counts for each CK for one record to be pr_loaded, or row-counts of database records matching each CK for which non-default values are supplied by a single table row object. Can CK-subclasses use key-matching method overrides? ------------------------------------- CQ conversion does atoi, encode, or strncmp depending on field type. IF CK could be subclassed (or templatized) not only on the TT-parent type but ALSO on the CKname, subclass method overrides could do the field conversions and value-maching. AFAIK, the latter is possible only at UNreasonable complexity. This dependence on named field types precludes using the Visitor Design Pattern (which depends on the entity type it visits to choose a conversion method). Making each CK-spec (CK-row instance) a new entity class would also lead to subclass proliferation. Unvoidability of switch cases when loading CQ test data: ------------------------------------------------------ I conclude that field value conversion (to take advantage of CK--->CA>--TA metadata) must be inside a switch(field_type) with cases {int, hcg_key, char*} to convert each CQ's field value. chgen does not generate such conversions on a field basis: it works from the TTcurr->ttabbr (but not CK--->CA>----TA's ftype) metadata to supply pr_load's switch(tbl_encoding) arguments. Therefore pr_load from chgen can only read and split the field value list (via hcg_parse). YOUR CODE must complete the task by converting each field value of a CQ according to its ftype. Chgen extension possibilities: ---------------------------- Right now chgen only converts a schema-specified list of field values for any table type XX, because chgen generates code within a switch(ttidx) case block for a given declared table type. An extension to chgen might generate keyExists methods automatically based on CK--->CA metadata. However, each named CK for each table type would have to be a distinct class (or a subclass of CQ). Then eack CK would be provided with the correct sequence of value-conversion and value-comparison expressions satisfying the types for its fvalue list. chgen vs. gencpp: ----------------- Chgen's pr_load.c:load_data method has a case block inside switch(tbl_encoding) for each schema table type XX. In fact pr_parse and pr_link both perform this switch. Chgen can be refactored (by reusing code from gencpp) to generate class-specific XXelt->load_row methods and calls. Gencpp already does this refactoring, doing only one switch(tbl_encoding) and calling parse_row and link_row. REF: A gencpp test for the DEpt-->COurse==>PQ (PreRequisite) subschema, $CASE/gen/gencpp/ver_1/test/test_co_pr.sch, (mush simpler than SISrev0461014.sch in asgnt3). This gencpp test is at this path: $CASE/gen/gencpp/ver_1/test. More details on chgen vs. gencpp refacgtoring are in this note (TBDiscussed later): $PH/06f522/chgen2gencppRefactoringProjects061022.txt R Lechner ----------------------------- > From nitin.sonawane@gmail.com Sun Oct 22 10:09:12 2006 > From: "Nitin Sonawane" > To: "Bob Lechner" , "Alison Miles" , > Prof Lechner, > > I was wondering if we really need a query table "CQ" for assignment three. > So far, I have been assuming that we can have a simple ad-hoc querying > mechanism driven by two strings ckName & valueList passed to the proposed > keyExists() function. > > Perhaps it is clear to other classmates how we would use the CQ table, it is > not very clear to me. > - would the CQ table simply contain a string representation of candidate > keys? > - would the CQ table also contain values? > > Any advise would be appreciated. I have some start on the test driver and > would like to make progress this weekend. > > Thanks, > Nitin.