TableDescriptions

From genomewiki
Jump to: navigation, search

Each database has (or should have) a tableDescriptions table whose purpose in life is to augment the sql table description that the Table Browser displays when the user clicks "describe table schema". tableDescriptions has three columns:

  • tableName: the name of a database table -- omitting the "chr*_" prefix for split tables.
  • autoSqlDef: (if we can find it) the autoSql table definition for this table.
  • gbdAnchor: (if we can find it) the HTML anchor tag in goldenPath/gbdDescriptions.html for this table.

There are two programs that are used to build tableDescriptions in different databases:

  • kent/src/test/buildTableDescriptions.pl: this script is intended for genome databases, to which we frequently add new tables. It reads in all .as files in the kent/src tree, except for a few that it ignores due to table name conflicts (many of the .as files reside in the directory kent/src/hg/lib/). Then, for each database table, it looks for an autoSql table definition with the same name. If it finds one, that is what it uses. If there is no autoSql def with the right table name, then it looks for one that describes the exact same fields. So, for example, a single .as file that describes PSL can be used for all PSL tables.
  • makeTableDescriptions: this C program is intended for monolithic/standalone databases such as visiGene or uniProt. Unlike genome databases, these databases are usually updated all at once, and there is usually a single .as file (or a small number of .as files) that describes all tables in the database.

buildTableDescriptions.pl is run nightly by cron jobs on hgwdev and hgwbeta, updating the tableDescriptions table in each genome db. It should be pushed to the RR regularly so that RR tableDescriptions tables remain current. It would probably be a good idea to always push it along with trackDb.

makeTableDescriptions should be run every time that a monolithic database is updated, and the tableDescriptions table can be included in the push of the database (updates usually involve all tables or simply a brand new version of the database).

Navigation: back to Implementation_Notes