.IP \[bu]
injuriesxml.dtd
.IP \[bu]
+MLB_Gaming_Matchup_XML.dtd (GameInfo)
+.IP \[bu]
+MLB_Lineup_XML.dtd (GameInfo)
+.IP \[bu]
+MLB_Matchup_XML.dtd (GameInfo)
+.IP \[bu]
+MLS_Preview_XML.dtd (GameInfo)
+.IP \[bu]
+mlbpreviewxml.dtd (GameInfo)
+.IP \[bu]
+NBA_Gaming_Matchup_XML.dtd (GameInfo)
+.IP \[bu]
+NBA_Playoff_Matchup_XML.dtd (GameInfo)
+.IP \[bu]
+NBALineupXML.dtd (GameInfo)
+.IP \[bu]
+nbapreviewxml.dtd (GameInfo)
+.IP \[bu]
newsxml.dtd
.IP \[bu]
+nhlpreviewxml.dtd (GameInfo)
+.IP \[bu]
Odds_XML.dtd
.IP \[bu]
+recapxml.dtd (GameInfo)
+.IP \[bu]
scoresxml.dtd
.IP \[bu]
weatherxml.dtd
+.P
+The GameInfo and SportsInfo types do not have their own top-level
+tables in the database. Instead, their raw XML is stored in either the
+\(dqgame_info\(dq or \(dqsports_info\(dq table respectively.
.SH DATABASE SCHEMA
.P
-At the top level, we have one table for each of the XML document types
-that we import. For example, the documents corresponding to
-\fInewsxml.dtd\fR will have a table called \(dqnews\(dq. All top-level
-tables contain two important fields, \(dqxml_file_id\(dq and
-\(dqtime_stamp\(dq. The former is unique and prevents us from
-inserting the same data twice. The time stamp on the other hand lets
-us know when the data is old and can be removed. The database schema
-make it possible to delete only the outdated top-level records; all
-transient children should be removed by triggers.
+At the top level (with two notable exceptions), we have one table for
+each of the XML document types that we import. For example, the
+documents corresponding to \fInewsxml.dtd\fR will have a table called
+\(dqnews\(dq. All top-level tables contain two important fields,
+\(dqxml_file_id\(dq and \(dqtime_stamp\(dq. The former is unique and
+prevents us from inserting the same data twice. The time stamp on the
+other hand lets us know when the data is old and can be removed. The
+database schema make it possible to delete only the outdated top-level
+records; all transient children should be removed by triggers.
.P
These top-level tables will often have children. For example, each
news item has zero or more locations associated with it. The child
unique constraint in the top-level table's \(dqxml_file_id\(dq will
prevent duplication in this case anyway.
.P
+The aforementioned exceptions are the \(dqgame_info\(dq and
+\(dqsports_info\(dq tables. These tables contain the raw XML for a
+number of DTDs that are not handled individually. This is partially
+for backwards-compatibility with a legacy implementation, but is
+mostly a stopgap due to a lack of resources at the moment. These two
+tables (game_info and sports_info) still possess timestamps that allow
+us to prune old data.
+.P
UML diagrams of the resulting database schema for each XML document
type are provided with the \fBhtsn-import\fR documentation.
construct the DTDs ourselves, the results are sometimes
inconsistent. Here we document a few of them.
-.IP \[bu]
-2 Odds_XML.dtd
+.IP \[bu] 2
+Odds_XML.dtd
The <Notes> elements here are supposed to be associated with a set of
<Game> elements, but since the pair
import qualified TSN.XML.AutoRacingSchedule as AutoRacingSchedule (
dtd,
pickle_message )
-import qualified TSN.XML.GameInfo as GameInfo ( dtds )
+import qualified TSN.XML.GameInfo as GameInfo ( dtds, parse_xml )
import qualified TSN.XML.Heartbeat as Heartbeat ( dtd, verify )
import qualified TSN.XML.Injuries as Injuries ( dtd, pickle_message )
import qualified TSN.XML.InjuriesDetail as InjuriesDetail (
let m = unpickleDoc Weather.pickle_message xml
maybe (return $ ImportFailed errmsg) migrate_and_import m
- | dtd `elem` GameInfo.dtds = undefined
+ | dtd `elem` GameInfo.dtds = do
+ let either_m = GameInfo.parse_xml dtd xml
+ case either_m of
+ -- This might give us a slightly better error
+ -- message than the default 'errmsg'.
+ Left err -> return $ ImportFailed err
+ Right m -> migrate_and_import m
| dtd `elem` SportInfo.dtds = undefined