Edgewall Software

Changes between Version 4 and Version 5 of Data Storage


Ignore:
Timestamp:
Sep 23, 2005, 3:48:55 PM (19 years ago)
Author:
cmlenz
Comment:

Minor corrections/clarifications

Legend:

Unmodified
Added
Removed
Modified
  • Data Storage

    v4 v5  
    1616 * Total lines of code in the unit
    1717 * Percentage of lines executed
    18  * Number of times every lin was executed
     18 * Number of times every line was executed
    1919
    20 Other data such as compilation errors/warnings or style checks would consist of the message of the error or warning.
     20Other data such as style check results would in turn consist of other properties.
    2121
    2222== Database Schema ==
     
    2828[[Image(tables.png)]]
    2929
    30 There is one `bitten_report` record per report. This record associates the report with a step of a specific build (see ObjectModel), and stores the ''category'' and the ''generator'' of the report. The category can be seen as indicator of the schema with which the report data complies. For example, there's a category "test" for test results, and a category "coverage" for code coverage. Test results data may be generated by different recipe commands and tools, but as long as they comply with the schema of the "test" category, the data can be analyzed and visualized by the same generic components.
     30There is one `bitten_report` record per report. This record associates the report with a step of a specific build (see ObjectModel), and stores the ''category'' and the ''generator'' of the report.
    3131
    32 The report data itself is stored in the `bitten_report_item` table. The basic assumption is that a report consists of a flat, unordered list of data points, each having a variable set of named properties. The names and values of these properties are storeds in the `name` and `value` columns of the `bitten_report_item` table, respectively. The `item` column simply contains a number that groups the individual properties into "report items".
     32  ''The category can be seen as indicator of the schema with which the report data complies. For example, there's a category “test” for test results, and a category “coverage” for code coverage. Test results data may be generated by different recipe commands and tools, but as long as they comply with the schema of a known category, the data can be analyzed and visualized by the same generic components.''
     33
     34The report data itself is stored in the `bitten_report_item` table. The basic assumption is that a report consists of a flat, unordered list of data points, each having a variable set of named properties. The names and values of these properties are storeds in the `name` and `value` columns of the `bitten_report_item` table, respectively. The `item` column simply contains an artificial key that groups the individual properties into "report items".
    3335
    3436== Mapping XML Reports to Database Tables ==
     
    4850}}}
    4951
    50 For such a report, Bitten first inserts a record into the `bitten_report` table, taking the category and generator from the corresponding attributes of the `<report>` element. Next, a couple of records are inserted into the `bitten_report_item` table for every immediate child element of `<report>`; one for every attribute of the child element. In addition, the tag name is stored as a property named `type`.
     52For such a report, Bitten first inserts a record into the `bitten_report` table, taking the category and generator from the corresponding attributes of the `<report>` element. Next, a couple of records are inserted into the `bitten_report_item` table for every child element of `<report>`; one for every attribute of the child element. In addition, the tag name is stored as a property named `type`.
    5153
    52 Children of the child element are also mapped to properties: here the tag name of the "grandchild" is used as the property name, and its´ body text is used as the property value.
     54To allow for the transmission of data that cannot be easily encoded into XML attribute values, children of the child element itself are also mapped to properties: the tag name of the “grandchild” is used as the property name, and its´ body text is used as the property value.
    5355
    54 So the following snippets would be stored in exactly the same way:
     56For example, the following snippets would be stored in exactly the same way:
    5557
    5658{{{
     
    7375}}}
    7476
    75 These two methods can be mixed. When multiple child elements with the same tag name are encountered, only the last one is stored.
     77These two methods can be mixed. When multiple properties with the same name are encountered, only the last one is stored. Child elements take precedence over attributes.
    7678
    77 The tables will contain the following data for this report:
     79For the example above, the database tables should contain the following data:
    7880
    7981'''`bitten_report`''':
     
    8385'''`bitten_report_item`''':
    8486|| report || item || name       || value                                     ||
    85 || 123    || 1    || `type`     || `test`                                    ||
    86 || 123    || 1    || `duration` || `0.073`                                   ||
    87 || 123    || 1    || `status`   || `success`                                 ||
    88 || 123    || 1    || `fixture`  || `bitten.tests.model.BuildConfigTestCase`  ||
    89 || 123    || 1    || `name`     || `test_config_update_name`                 ||
    90 || 123    || 1    || `file`     || `bitten/tests/model.py`                   ||
    91 || 123    || 1    || `stdout`   || `Renaming build configuration`            ||
     87|| 123    || bar   || `type`     || `test`                                    ||
     88|| 123    || bar   || `duration` || `0.073`                                   ||
     89|| 123    || bar   || `status`   || `success`                                 ||
     90|| 123    || bar   || `fixture`  || `bitten.tests.model.BuildConfigTestCase`  ||
     91|| 123    || bar   || `name`     || `test_config_update_name`                 ||
     92|| 123    || bar   || `file`     || `bitten/tests/model.py`                   ||
     93|| 123    || bar   || `stdout`   || `Renaming build configuration`            ||
    9294
    9395== Querying the Report Store ==
    9496
    95 Querying the report data is not straight-forward due to the generic nature of the tables. This usually requires a number of self-joins.
     97Querying the report data is not straight-forward due to the generic nature of the tables. This usually results in a number of “self-joins” in the SQL `SELECT` statement.
    9698
    9799For example, the following query aggregates the number of failed/succeeded unit tests by fixture:
     
    122124}}}
    123125
    124   ''(This code is from the [source://trunk/bitten/trac_ext/summarizers.py TestResultsSummarizer].)''
     126  ''(This code is from the [source://trunk/bitten/trac_ext/summarizers.py TestResultsSummarizer] component in Bitten.)''