# create the database isip_varmint to hold the bug-tracking tables
#
create database if not exists isip_varmint;

# connect to our new database
#
connect isip_varmint;

# build the data dictionary table first
#
create table bug_list(
       BugNumber int unsigned not null,
       Title varchar(100),
       Owner varchar(30),
       Status varchar(15),
       Priority varchar(10),
       Severity varchar(25),
       DBase varchar(20),
       OpenedBy varchar(30),
       OpenDate datetime,
       Environment varchar(50),
       Component varchar(20),
       TestCase varchar(30),
       Class varchar(40),
       ResolvedBy varchar(30),
       Resolution varchar(20),
       ResolvedDate datetime,
       ReviewDate datetime,
       Inspected varchar(30),
       Due varchar(25),
       Description blob,
       ClosedDate datetime,
       LockedBy varchar(30),
       ModifyDate datetime,
       primary key(BugNumber, DBase));

# build the configuration table
#
create table config(
       cindex int auto_increment,
       cname  varchar(50) not null, 
       cdisplay varchar(50),
       cvals varchar(500),
       cdef varchar(50),
       primary key(cindex));

# build the component table
#
create table component(
       cindex int auto_increment,
       DB varchar(10) not null,
       component varchar(500),
       primary key(cindex));	

# build the groups table
#
create table groups(
       gindex int auto_increment,
       gname varchar(50),
       users varchar(500),
       primary key(gindex));

# build the queries table
#
create table queries(
       qindex int auto_increment,
       Description varchar(100),
       Owner varchar(30),
       Query varchar(500),
       Shared varchar(20),
       primary key(qindex));


# populate the configuration table with fields from the dictionary
# it would be nice if this was automated, but it's not in MySql
# also, give the type of each field, either 'text' or enumeration values
#
insert into config values('BugNumber','text');
insert into config values('Title','text');
insert into config values('Owner','duncan, king, langley');
insert into config values('Status','open, resolved, closed');
insert into config values('Priority','high, medium, low');
insert into config values('Severity','critical, serious, non-critical');
insert into config values('DBase','ifc, eval');
insert into config values('OpenedBy','text');
insert into config values('OpenDate','text');
insert into config values('Environment','SPARC Solaris 2.7, i386 Solaris 2.7, Redhat XXX, All');
insert into config values('Component','ifc, evals');
insert into config values('TestCase','diagnose, external, none, n/a');
insert into config values('Class','project, defect, design change');
insert into config values('ResolvedBy','text');
insert into config values('Resolution','fixed, acceptable, duplicate, suspended, mistaken');
insert into config values('ResolvedDate','text');
insert into config values('ReviewDate','text');
insert into config values('Inspected','text');
insert into config values('Due','text');
insert into config values('Description','text');

# all values inserted into config
#

# Notes: The values of Owner, OpenedBy, ResolvedBy, and Inspected are
# all checked against the values in Owner.  This saves some space in
# the database files.
#

# Notes:  Some of the items listed in the design spec as enum's are not
# impletmented as such here.  I used SQL enumerations where we actually know 
# full range of values we want to use, but in some cases, we don't really 
# want enumerations.  See the OpenedBy, ResolvedBy, Owner, and similar fields.
# These fields will all contain the same values, but the values aren't 
# guaranteed to remain fixed.  I propose these enum's be implemented in the 
# Java portion of the code instead, as we can pull the user names out of a 
# central file (such as the isip mailing list) and always be up to date.
#
# In the case of the Due field, this shouldn't be enumerated in SQL as we 
# don't know what the full range of our revision numbers will be at this time.
#

# Notes: I'm using unixdate types for storing dates like I do in the Software 
# Checklist. I will encapsulate the conversion of unixdate types to strings
# in my DBMS interface class.
#

# Notes: In some cases, my choices of data types are appropriate, but may not 
# fulfill the full requirements of the program.  For example, the type of the 
# Description field is mediumblob - which allows room for 16 million 
# characters.  This seems a bit much space to use, but the next smaller type
# only allows room for 65 kChars, which may not be enough for some bugs.
# We can increase the space to 4 billion chars, reduce to 65k, or stay put.
# 

# Notes: I will wait to write the rest of the procedures until you approve the 
# create statements.
# JRL - 8/31/00
#




