[Gusdev-gusdev] Preliminary 3.0 schema files in CVS.

[Jonathan C. <cra...@sn...>]

I've just committed the preliminary GUS 3.0 schema into the shared CVS
repository on cvs.sanger.ac.uk (in GUS/Model/schema/oracle).  It's
preliminary because I haven't done a full test yet (i.e., check out a
clean copy from CVS and use it to create a new GUS instance.)  In fact,
I know there's at least one bug that was probably introduced by some
changes that Steve and I made to the build system earlier today.  These
changes should make it much easier to install the schema, because the
user/DBA is now presented with a single file that has to be customized
(with Oracle passwords, tablespace names, quotas, etc.).  Once that file
is customized, building the system will generate a site-specific set of
schema installation scripts that can then be run directly from SQL*PLUS,
without further modification.  However, I believe that these changes are
interacting in an undesirable way with another part of the build system,
and we have to debug the problem (which I don't think will take long.)
In the meantime, there is a simple workaround; when the build process
fails--complaining that somedirectory/Model/Core does not exist--simply
create that directory (and the corresponding ones for the other GUS
namespaces) and re-run the build command.

In any case, there are also a few other things that need to be cleaned up.
The installation documentation needs to be brought up to date and, as
mentioned above, I have to finish testing what's now in CVS before tagging
it as an official release.  In particular, I suspect that the schema
creation files may contain some illegal identifiers (e.g., some
automatically-generated names may exceed the Oracle-imposed 30 character
limit.)  We plan to tag the first release as version '3.0-1.0', to
indicate that the GUS schema version is 3.0 and the code version is 1.0;
this convention should make it easy to tell whether the schema has changed
in any given release.  We also plan to keep migration scripts (e.g. to
convert a GUS 3.0 database instance into a GUS 3.1 database instance) in
GUS/Model/schema/oracle/migrate.  Eventually, when we add support for
MySQL or PostgresQL, those files will go in GUS/Model/mysql or
GUS/Model/postgresql.  By the way, "Model" is Steve's abbreviation for
"data model", the idea being that this directory encompasses everything
that relates to our data model.  This includes both the database schema
and also any behavior associated with the "objects" defined in the schema
(i.e., the Perl and Java code.)

I think that's all I have to report for now.  Arnaud, I'm afraid I
haven't done anything about the repeat regions yet; it's on my the short
list of things to do once we get this initial release done.  If you have
any questions about the build process/install scripts before I wake up
today, give Steve a call.  Once the schema files have been successfully
"built", look at $GUS_HOME/schema/oracle/create-db.sh; this script uses
SQL*PLUS to run each of the individual .sql files in the correct order.
The output of each .sql file is logged to a corresponding .log file,
although I have yet to implement any kind of checking mechanism (for
example, to grep through the .log file and check that the correct number
of tables/views were created.)

Jonathan