From: Steve F. <st...@pc...> - 2003-02-12 15:28:59
|
folks- i have fixed the bug jonathan mentions below. i am putting some finishing touches on the build system (stuff relating to the new configuration process). i will be checking it in within the hour probably. i'll let you know then. in order to get going with the schema, you need to install gus and the build system. see http://www.gusdb.org/BuildSystemSetup.html steve Jonathan Crabtree wrote: >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 > > > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >http://www.vasoftware.com >_______________________________________________ >Gusdev-gusdev mailing list >Gus...@li... >https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > |