Changes between Version 2 and Version 3 of Data Storage

Timestamp:

Sep 19, 2005, 8:12:53 PM (19 years ago)

Author:

cmlenz

Comment:

Removed BDB XML stuff

Data Storage

@@ -11 +11 @@
  * Time it took to execute the test
 
-Other data such as compilation errors and warnings would only consist of the message of the error or warning. Code coverage would annotate each line in the code base with the number of times that line has been executed, and in addition accumulate coverage statistics on a per-file or per-class basis.
+Code coverage, on the other hand, might look like this:
 
-== XML Database Backend ==
+ * Name of the unit (module, class, etc)
+ * Total lines of code in the unit
+ * Percentage of lines executed
+ * Number of times every lin was executed
 
-Semi-structured data such as this is not a good candidate for storage in a relational database. Instead, native XML databases are rather well suited for storing semi-structured data. Bitten therefore uses [http://www.sleepycat.com/products/xml.shtml Berkeley DB XML] to store reports generated by builds. BDB XML supports the [http://www.w3.org/TR/xquery/ XQuery] standard and thereby enables efficient and powerful analysis and aggregation of the collected software metrics.
+Other data such as compilation errors/warnings or style checks would consist of the message of the error or warning.
 
-  ''Note that Bitten allows an alternative XQuery capable data store being used instead of BDB XML.''
+== Database Layout ==
 
-Every report is stored as a self-contained document in the XML DB. It is associated with a specific build step using metadata:
+As Bitten should support the storage of arbritray metrics, the tables for storing this data need to be fairly generic. Versions of Bitten prior to [milestone:0.5] used a Berkeley DB XML backend to store reports, but for various reasons the report data is now mapped to tables in the relational database already provided by the Trac environment.
 
- `config`:: The name of the build configuration the report belongs to
- `build`:: The unique ID of the associated build
- `step`:: The name of the build step
-
-The reports themselves are stored verbatim as received from the build slave, for example:
+A report is received in XML format from the build slave, for example:
 
 {{{