gusdev-gusdev — Topics concerning GUS development

Re: [Gusdev-gusdev] grantPermissions.pl

[Steve F. <st...@pc...>]

chetna-

step 5. of the build system setup tells you what to do with PERL5LIB. 
 (we added this about a week ago, so you might have missed it).

you need to add $GUS_HOME/lib/perl to the front of PERL5LIB.  I suspect 
that much of the rest of the stuff in there is unneeded. (it might have 
been from the the old gus)

in any case, the first element in your @INC shouldn't be there.  maybe 
you put it there to try to solve the problem?

steve

Chetna Warade wrote:

>Hi,
>
>I ran the create-db.sh script and the grantPermissions.pl fails and
>thats why the constraints script fails. All the users and tables are
>correctly created. 
>
>I have strictly followed all the steps and setting up the env variables as
>the Build System Set up doc says except the point 7 (steve recommended
>that choice as I could download stuff from cvsweb too)
>
>[chetna@mango chetna]$ grantPermissions.pl
>Can't locate GUS/DBAdmin/Database.pm in @INC (@INC contains:
>/home/projects/GUS/DBAdmin/lib/perl /home/projects/lib
>/usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1
>/usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1
>/usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0
>/usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux
>/usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl .) at
>/home/gus_home/bin/grantPermissions.pl line 15.
>BEGIN failed--compilation aborted at
>/home/gus_home/bin/grantPermissions.pl line 15.
>[chetna@mango chetna]$
>
>I am observing that the @INC stuff is actually using PERL5LIB env variable
>from my .bash_profile and the Build System doesnt talk about this var.
>
>Please let me know how to debug the grantPermissions.pl.
>
>Thanks
>Chetna
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
>The most comprehensive and flexible code editor you can use.
>Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
>www.slickedit.com/sourceforge
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>
>  
>

[Gusdev-gusdev] grantPermissions.pl

[Chetna W. <ch...@ar...>]

Hi,

I ran the create-db.sh script and the grantPermissions.pl fails and
thats why the constraints script fails. All the users and tables are
correctly created. 

I have strictly followed all the steps and setting up the env variables as
the Build System Set up doc says except the point 7 (steve recommended
that choice as I could download stuff from cvsweb too)

[chetna@mango chetna]$ grantPermissions.pl
Can't locate GUS/DBAdmin/Database.pm in @INC (@INC contains:
/home/projects/GUS/DBAdmin/lib/perl /home/projects/lib
/usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1
/usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1
/usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux
/usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl .) at
/home/gus_home/bin/grantPermissions.pl line 15.
BEGIN failed--compilation aborted at
/home/gus_home/bin/grantPermissions.pl line 15.
[chetna@mango chetna]$

I am observing that the @INC stuff is actually using PERL5LIB env variable
from my .bash_profile and the Build System doesnt talk about this var.

Please let me know how to debug the grantPermissions.pl.

Thanks
Chetna

Re: [Gusdev-gusdev] Rollback segment configuration

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

Arnaud-

Arnaud Kerhornou wrote:
> During the build process, the only thing which doesn't work properly is 
> the rollback segment piece of code in RelationalRow.pm. Do you remember 
> we have already talked about this, and we, here, kept the default 
> segment rollback configuration while at CBIL you're using a big one, 
> called 'BIGRBS0'.
> Would it be possible to set the rollback segment name in a configuration 
> file to make sure it is compliant with any Oracle instance setup?

Yes, sorry about that; it was an oversight on our part.  The configuration
file should also allow you to tell the object layer not to set the rollback
segment name at all (i.e. to use the default.)  I'll put this in the SourceForge
bug tracker as soon as I get out of my meeting(s).

Jonathan

[Gusdev-gusdev] Rollback segment configuration

[Arnaud K. <ax...@sa...>]

Jonathan

During the build process, the only thing which doesn't work properly is 
the rollback segment piece of code in RelationalRow.pm. Do you remember 
we have already talked about this, and we, here, kept the default 
segment rollback configuration while at CBIL you're using a big one, 
called 'BIGRBS0'.
Would it be possible to set the rollback segment name in a configuration 
file to make sure it is compliant with any Oracle instance setup?

cheers
Arnaud

Re: [Gusdev-gusdev] grantPermissions.pl

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

Hi Chetna-

On Mon, 17 Feb 2003, Chetna Warade wrote:
> 1) The FileNotFoundException occured because java was not able to find
> build.xml located in the GUS project (point 8 in Build System set up html

OK, my mistake; I didn't realize that you hadn't downloaded the GUS
project.

> - In summary the BuildSystemsetup should mention to download both CBIL and
> GUS projects.

Point 7 does say that you should check out the GUS and install projects
from the Sanger CVS repository (and provides the command for doing so,
lest you should misconstrue "check out" to mean "look at.")  However, we
could reword point 8 so that it says something like this:

"At a minimum you will need to get the CBIL project (in addition to the
GUS and install projects, which you should have downloaded in step 7.)"

> 2) I tried running grantPermissions.pl (standlone with perl) and here's
> the problem. The GUS project that I downloaded from cvsweb has the
> directory structure: /home/projects/GUS/DBAdmin/lib/perl/*.pm
>
> and the grantPremissions.pl has:
>
> use GUS::DBAdmin::Database;
> use GUS::DBAdmin::Schema;
>
> which is why it fails. I am not quite sure if the build creates this
> grantPermissions.pl but I dont know how to fix the discrepancy in the
> directory structure (I could make changes though). Thats why I havent run
> the create-db.sh script. Also permission of grantPermission.pl is not set
> as executable. Maybe it should.

The build process creates a new copy of this script in your $GUS_HOME,
and makes it executable.  It will also copy the library (.pm) files to a
location in your $GUS_HOME, where they *will* conform to the directory
structure that you would expect from the package names.  If you follow
all of the setup directions (including setting your PATH and other
environment variables as indicated), then you should end up with the
grantPermissions.pl in your PATH (i.e. you should be able to just say
'rehash; grantPermissions.pl' and have it find and run the script
correctly.)  I'll try to improve the documentation to explain some of
these things a little more thoroughly.

Jonathan

[Gusdev-gusdev] grantPermissions.pl

[Chetna W. <ch...@ar...>]

Hi,

1) The FileNotFoundException occured because java was not able to find
build.xml located in the GUS project (point 8 in Build System set up html
page at gusdb.org). Point 8 in the Build System setup document says 
"At a minimum you need the CBIL project because GUS depends upon it..  You
may also get other CBIL projects as needed." Thats why I downloaded only
CBIL project as there were many projects and I found that confusing. In
order to solve this problem then I downloaded the GUS project from
cvsweb.sanger.ac.uk as that was the latest and GUS project at gusdb.org
was older. This solved my problem of FileNotFoundException.

- In summary the BuildSystemsetup should mention to download both CBIL and
GUS projects.

2) I tried running grantPermissions.pl (standlone with perl) and here's
the problem. The GUS project that I downloaded from cvsweb has the
directory structure: /home/projects/GUS/DBAdmin/lib/perl/*.pm

and the grantPremissions.pl has:

use GUS::DBAdmin::Database;
use GUS::DBAdmin::Schema;
 
which is why it fails. I am not quite sure if the build creates this
grantPermissions.pl but I dont know how to fix the discrepancy in the
directory structure (I could make changes though). Thats why I havent run
the create-db.sh script. Also permission of grantPermission.pl is not set
as executable. Maybe it should.

Chetna

Re: [Gusdev-gusdev] schema.prop

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

Chetna-

On Mon, 17 Feb 2003, Chetna Warade wrote:
>
> BUILD FAILED
> file:/home/projects/install/build.xml:228:
>       Error: You must configure the file
> /home/gus_home/config/install.prop.  To create it, copy
> /home/gus_home/config/install.prop.sample to
> /home/gus_home/config/install.prop and edit
> /home/gus_home/config/install.prop, giving it the proper values for your
> installation.
>

Did you follow these instructions?  The reason that you're getting a
FileNotFoundException is that the build system is looking for a file
called $GUS_HOME/config/install.prop.  As the above directions indicate,
you're supposed to copy "install.prop.sample" (which is in the same
directory) to "install.prop" and then edit "install.prop" to match your
site's configuration.  Maybe we should change the message to say "You must
create the file ..." instead of "You must configure the file ...", since
the latter suggests that the file exists already.

This file is there to let you configure things that might be different
between different installations of GUS.  At the moment it only contains a
single property, which is the location of the Perl interpreter.  If your
Perl interpreter is /usr/bin/perl then you can simply use the default
file (although you still have to copy it into install.prop)  Let me know
if this makes sense, and, if so, how you think we could make the
directions clearer.  Thanks,

Jonathan

Re: [Gusdev-gusdev] schema features v. patches

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

On Mon, 17 Feb 2003, Steve Fischer wrote:
> so, is there any operational difference between a patch and a release?
>  or is the only thing different which digit of the release number is
> affected?

In terms of the CVS structure and migration scripts, no, I don't think
there is any difference.  However, for users who aren't using CVS and who
are downloading tar'ed releases, a patch will typically consist of a
smaller set of files that you can install "on top of" or alongside an
existing full release.  We'll have to think about exactly how to implement
this, but here's one possibility; a tar file that contains

 1. Another tar file, which contains all the files under $PROJECT_HOME
    that have changed (or just the diffs, if we want to get fancy.)
 2. The schema migration scripts, which will make the database reflect the
    new files installed from 1.

After installing both of these parts we'd instruct people to re-install to
$GUS_HOME.

Jonathan

[Gusdev-gusdev] install.prop

[Chetna W. <ch...@ar...>]

Hi,

Sorry guys I gave a mistmatched subject line and email matter. I copied
install.prop in /home/gus_home/config.

1) I still want to know what are the changes in the install.prop

2) [chetna@mango install]$ build GUS install -append

ant -f /home/projects/install/build.xml install -Dproj=GUS
-DtargetDir=/home/gus_home -Dcomp= -DprojectsDir=/home/projects
-Dappend=true -logger org.apache.tools.ant.NoBannerLogger | grep ']'


BUILD FAILED
file:/home/projects/install/build.xml:24: java.io.FileNotFoundException:
/home/projects/GUS/build.xml (No such file or directory)

Total time: 1 second
[chetna@mango install]$

I am wondering if the changes in (1) is related to (2)?

Chetna

[Gusdev-gusdev] schema.prop

[Chetna W. <ch...@ar...>]

Hi,

I installed Ant 1.5.1 and the isfalse problem seems to disappear. 
What are the changes in the install.prop? It would be great if someone can
give insight.
I am pasting the following:

[chetna@mango install]$ build GUS install -append

ant -f /home/projects/install/build.xml install -Dproj=GUS
-DtargetDir=/home/gus_home -Dcomp= -DprojectsDir=/home/projects
-Dappend=true -logger org.apache.tools.ant.NoBannerLogger | grep ']'


BUILD FAILED
file:/home/projects/install/build.xml:228:
      Error: You must configure the file
/home/gus_home/config/install.prop.  To create it, copy
/home/gus_home/config/install.prop.sample to
/home/gus_home/config/install.prop and edit
/home/gus_home/config/install.prop, giving it the proper values for your
installation.


Total time: 1 second
[chetna@mango install]$

Hope to hear from you
Chetna


> I've tested the GUS 3.0 schema creation scripts and have tagged the
> current release in CVS as 'schema30-code10' (i.e., GUS schema version
> 3.0, code version 1.0.)  Here's the install process in a nutshell:
> 
>  1. Install the GUS code as described on the gusdb.org web site
>     (at <http://www.gusdb.org/BuildSystemSetup.html>)  During the
>     installation the build system should tell you to create the
>     properties file $GUS_HOME/config/schema.prop;  this file
>     should be edited in order to customize the schema installation
>     scripts to your site and Oracle database instance.
> 
>     (As an aside, if you don't want to place the Oracle SYS password
>     in this file, you can instead choose to run the schema creation
>     scripts manually, since only of the scripts must be run with
>     SYS/DBA privileges.  In fact, now that I think of it, the script
>     in question could be run by any user with the ability to create
>     user accounts.  I'll put changing this on the to-do list.)
> 
>  2. Once the install is complete, cd to $GUS_HOME/schema/oracle
>  3. Make sure that the Oracle utility 'sqlplus' is in your $PATH.
>  4. Make sure that $GUS_HOME/bin is in your path and that you can
>     execute the scripts therein.
> 
>     (Another aside; not all of the scripts have been updated to
>     the new Perl package structure, but the only one we care
>     about for this step is grantPermissions.pl and you can try
>     running it on the command line--it should display a short
>     usage message if successful.)
> 
>  5. Review $GUS_HOME/schema/oracle/create-db.sh to make sure that
>     it's not going to do anything that you're unhappy with...
>  6. Run ./create-db.sh (Or, if you're using the manual install method,
>     run the commands contained in this file in the order given.)
>  7. Check that all of the scripts and/or commands in create-db.sh
>     ran successfully.
> 
>     (This step still needs to be automated.  For now you can either
>     query the Oracle system tables to check that the correct number
>     of uses/tables/etc. were created, or grep the .log files for the
>     same information.  At the end of each .sql file is a line stating
>     how many CREATE statements are in that file, which can be compared
>     to the query or grep results.)
> 
> I won't be in the lab. tomorrow/today (Friday) but people in the lab.
> should be able to reach me by mobile phone if there are any questions
> or problems.
> 
> Jonathan
> 
> 

Re: [Gusdev-gusdev] schema features v. patches

[Steve F. <st...@pc...>]

about the "group" for bugs:  yes, it the version of the system that 
contained the bug.  (that is what i meant to say)

so, is there any operational difference between a patch and a release? 
 or is the only thing different which digit of the release number is 
affected?

steve

Jonathan Crabtree wrote:

>On Mon, 17 Feb 2003, Steve Fischer wrote:
>  
>
>>1. we need to decide which version of the schema the public schema
>>browser points to.  it seems to me that it must always point to the most
>>recent official version of the schema.  at CBIL, this might mean we need
>>a db instance which is neither production nor development that houses
>>the official schema.
>>    
>>
>
>Yes, this is definitely true.  Since the current schema browser requires
>an installed GUS instance, we'll either have to solve the multiple GUS
>instances per Oracle instance problem, or perhaps set up a separate small
>Oracle instance.
>
>  
>
>>2. i am going to venture the following tentative definition of a bug:
>>     - a correction to something we are already modelling
>>     - does not introduce any new tables
>>     - can it introduce new attributes?
>>     - *does not require migrating data*
>>    
>>
>
>I don't think this is the right approach.  If the system does not perform
>according to its documented specifications (or, more informally, if it
>doesn't do what it's expected or supposed to), then there is a bug.  The
>question of how much (and what kind) of work would be required to fix the
>bug is an entirely separate question (and one that I think should not have
>any bearing on whether the problem is in fact a bug.)  A bug fix could
>potentially introduce new tables or attributes, or even require migrating
>data.  It's very unlikely this would happen, but not impossible.  And,
>once we institute the policy of testing plugins before doing a schema
>release, the problem of having to modify the schema because it doesn't
>support everything the plugins want to do should disappear.
>
>  
>
>>3. if we do go with such a bug notion, then which tracker do we use?
>> here is a proposal:
>>    - all schema changes --bugs and features-- go to the schema feature
>>tracker (might have to rename it)
>>    - after we release a version of the schema (including a patched
>>version, eg 3.0.1) we add a "group" to the tracker called, eg, "3.0.1
>>(bug)"  and any bugs against that version are tagged with that group
>>    - after we release a version of the schema, we add a "group" for the
>>next version of the schema, eg "3.1".   feature requests are tagged with
>>this group.  ultimately, we decide as a team which requested features
>>are going to make it into the 3.1 release.  any that don't are either
>>re-tagged with the next release "3.2" or maybe relegated to a "not
>>scheduled yet" group.   Jonathan is responsible for making these changes
>>(expressing the consensus).
>>    
>>
>
>Sounds good, except I would prefer to associate bugs with the version of
>the schema that *contains* the bug, not the version of the schema that--if
>released--will (hopefully) fix it.
>
>  
>
>>4. we develop a light-weight mechanism for "patching" an instance, ie,
>>the scripts that will surgically make the patch.  these always work on
>>the most recent official version of the schema.  eg, patch 3.0.7 is only
>>officially applicable to the 3.0.6 version of the schema
>>    
>>
>
>Since we're incorporating the patch number into the version number system
>we've already developed, we don't need a separate system for the patch files;
>it will be the same as the system for the migration files.  Patches will
>hopefully be less work than migrations, but that may not always be the case.
>If you download release 3.0.2 and want to get to 3.0.7, you have to apply the
>following patches/migration scripts:
>
>3.0.2 -> 3.0.3
>3.0.3 -> 3.0.4
>3.0.4 -> 3.0.5
>3.0.5 -> 3.0.6
>3.0.6 -> 3.0.7
>
>Basically I'm not sure what you mean by a "light-weight" patching
>mechanism; the mechanism we've talked about for migrating from one release
>to the next is already light-weight, in the sense that it does the minimum
>amount of work needed to get from one to the other.
>
>Jonathan
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>
>  
>

Re: [Gusdev-gusdev] schema features v. patches

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

On Mon, 17 Feb 2003, Steve Fischer wrote:
> 1. we need to decide which version of the schema the public schema
> browser points to.  it seems to me that it must always point to the most
> recent official version of the schema.  at CBIL, this might mean we need
> a db instance which is neither production nor development that houses
> the official schema.

Yes, this is definitely true.  Since the current schema browser requires
an installed GUS instance, we'll either have to solve the multiple GUS
instances per Oracle instance problem, or perhaps set up a separate small
Oracle instance.

> 2. i am going to venture the following tentative definition of a bug:
>      - a correction to something we are already modelling
>      - does not introduce any new tables
>      - can it introduce new attributes?
>      - *does not require migrating data*

I don't think this is the right approach.  If the system does not perform
according to its documented specifications (or, more informally, if it
doesn't do what it's expected or supposed to), then there is a bug.  The
question of how much (and what kind) of work would be required to fix the
bug is an entirely separate question (and one that I think should not have
any bearing on whether the problem is in fact a bug.)  A bug fix could
potentially introduce new tables or attributes, or even require migrating
data.  It's very unlikely this would happen, but not impossible.  And,
once we institute the policy of testing plugins before doing a schema
release, the problem of having to modify the schema because it doesn't
support everything the plugins want to do should disappear.

> 3. if we do go with such a bug notion, then which tracker do we use?
>  here is a proposal:
>     - all schema changes --bugs and features-- go to the schema feature
> tracker (might have to rename it)
>     - after we release a version of the schema (including a patched
> version, eg 3.0.1) we add a "group" to the tracker called, eg, "3.0.1
> (bug)"  and any bugs against that version are tagged with that group
>     - after we release a version of the schema, we add a "group" for the
> next version of the schema, eg "3.1".   feature requests are tagged with
> this group.  ultimately, we decide as a team which requested features
> are going to make it into the 3.1 release.  any that don't are either
> re-tagged with the next release "3.2" or maybe relegated to a "not
> scheduled yet" group.   Jonathan is responsible for making these changes
> (expressing the consensus).

Sounds good, except I would prefer to associate bugs with the version of
the schema that *contains* the bug, not the version of the schema that--if
released--will (hopefully) fix it.

> 4. we develop a light-weight mechanism for "patching" an instance, ie,
> the scripts that will surgically make the patch.  these always work on
> the most recent official version of the schema.  eg, patch 3.0.7 is only
> officially applicable to the 3.0.6 version of the schema

Since we're incorporating the patch number into the version number system
we've already developed, we don't need a separate system for the patch files;
it will be the same as the system for the migration files.  Patches will
hopefully be less work than migrations, but that may not always be the case.
If you download release 3.0.2 and want to get to 3.0.7, you have to apply the
following patches/migration scripts:

3.0.2 -> 3.0.3
3.0.3 -> 3.0.4
3.0.4 -> 3.0.5
3.0.5 -> 3.0.6
3.0.6 -> 3.0.7

Basically I'm not sure what you mean by a "light-weight" patching
mechanism; the mechanism we've talked about for migrating from one release
to the next is already light-weight, in the sense that it does the minimum
amount of work needed to get from one to the other.

Jonathan

Re: [Gusdev-gusdev] Gus 3.0

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

Chetna-

> Please let me know which ant version you guys are using.

I've been using Ant version 1.5.1.  Steve, can you confirm that the
following error--

> BUILD FAILED
>
> /home/projects/install/build.xml:64: Class
> org.apache.tools.ant.taskdefs.condition.And doesn't support the nested
> "isfalse" element.

--is due to the Ant version mismatch?  It certainly looks like it might be
complaining about a feature that was only added in version 1.5.  We should
update the documentation to require a recent (1.5+) Ant.

Jonathan

[Gusdev-gusdev] schema features v. patches

[Steve F. <st...@pc...>]

  folks-

as the mail thread attached demonstrates, we are trying to figure out 
how to handle changes to the schema.  (the case attached arose because 
we upgraded our dbEST parser but never got a chance to test it on the 
schema before the schema was released, and now we have an urgent need to 
run the dbEST parser).

as we know, jonathan crabtree is our point man on this issue.

the main goal i see is to have a light-weight process in place for 
handling this.

here are my thoughts:

1. we need to decide which version of the schema the public schema 
browser points to.  it seems to me that it must always point to the most 
recent official version of the schema.  at CBIL, this might mean we need 
a db instance which is neither production nor development that houses 
the official schema.

2. i am going to venture the following tentative definition of a bug:
     - a correction to something we are already modelling
     - does not introduce any new tables
     - can it introduce new attributes?
     - *does not require migrating data*

3. if we do go with such a bug notion, then which tracker do we use? 
 here is a proposal:
    - all schema changes --bugs and features-- go to the schema feature 
tracker (might have to rename it)
    - after we release a version of the schema (including a patched 
version, eg 3.0.1) we add a "group" to the tracker called, eg, "3.0.1 
(bug)"  and any bugs against that version are tagged with that group
    - after we release a version of the schema, we add a "group" for the 
next version of the schema, eg "3.1".   feature requests are tagged with 
this group.  ultimately, we decide as a team which requested features 
are going to make it into the 3.1 release.  any that don't are either 
re-tagged with the next release "3.2" or maybe relegated to a "not 
scheduled yet" group.   Jonathan is responsible for making these changes 
(expressing the consensus).

4. we develop a light-weight mechanism for "patching" an instance, ie, 
the scripts that will surgically make the patch.  these always work on 
the most recent official version of the schema.  eg, patch 3.0.7 is only 
officially applicable to the 3.0.6 version of the schema

steve

-------- Original Message --------
Subject: Re: dots.est.polyA_siganl
Date: Mon, 17 Feb 2003 10:14:42 -0500 (EST)
From: "Deborah F. Pinney" <pi...@sn...>
To: Angel Pizarro <an...@sn...>
CC: Jonathan Crabtree <cra...@sn...>, Steve Fischer 
<st...@pc...>, <cb...@sn...>



Please note, changes are needed for otehr tables too including Clone,
Library,  and NASequenceImp.

NaSequenceImpOn Mon, 17 Feb 2003, Angel Pizarro wrote:

> On Mon, 17 Feb 2003, Jonathan Crabtree wrote:
>
> >
> > On Fri, 14 Feb 2003, Angel Pizarro wrote:
> > >
> > > right, sorry about that, I changed the assignment from Bugs to GUS Schema
> > > Features and assigned category = DoTS and group = 3.0
> >
> > We could actually handle this (and changes like this) in one of two ways:
> >
> >  1. Treat this as a feature request/schema change for 3.1 (since 3.0 is
> >     now "out the door" in some sense).  In that case, the appropriate
> >     group would be 3.1, not 3.0 (and we would create schema change entries
> >     in group 3.1 *before* the release of that version, versus bug fixes
> >     for version 3.1, which would be assigned to that group only *after*
> >     3.1 has been released.)
> >  2. Treat this as a bug/omission in 3.0.  In this case the chosen category
> >     (3.0) is correct, but we then have to worry about the issue of
> >     providing patches (so that people who have already downloaded what
> >     they thought was the 3.0 release can get updated to the version with
> >     the "bug" fix).
> >
> > I'd be inclined to go with #1, except in cases where the change is quite
> > clearly a bug.  For example, if we know (and have documented that!) the
> > est.polyA_signal column is supposed to be an exact replica of a column in
> > dbEST, and we fail to give it the same datatype/constraints, then that
> > is clearly a bug.  The problems we're running into with EST table at the
> > moment will hopefully not happen in future because we plan to actually
> > test and "certify" all the plugins against the proposed schema before
> > doing a release.
>
> I am for #2 since it is as you say a known bug. Which was why I had
> originally submitted it as a bug report, until Steve said that was not the
> place for these things. As debbie noted in a very recent email, there are
> other bugs that need to be addressed. We can prvide one large patch for
> the EST table to encompass all of the needed changes, or give them
> piece-meal. Or both.
>
> Angel
>
> PS. Sorry, I forgot about the version table change to the polya_signal
> column. Shoddy workmanship. won't happen again.
>

Re: [Gusdev-gusdev] Gus 3.0

[Arnaud K. <ax...@sa...>]

Hi

I've been using ant 1.5 to install GUS and it's been working fine.

ant -version
Apache Ant version 1.5 compiled on July 9 2002

Arnaud

Chetna Warade wrote:

>Hi,
>
>I am trying to do:
>
>1) [chetna@mango install]$ build GUS install -append
>
>ant -f /home/projects/install/build.xml install -Dproj=GUS
>-DtargetDir=/home/gus_home -Dcomp= -DprojectsDir=/home/projects
>-Dappend=true -logger org.apache.tools.ant.NoBannerLogger | grep ']'
>
>BUILD FAILED
>
>/home/projects/install/build.xml:64: Class
>org.apache.tools.ant.taskdefs.condition.And doesn't support the nested
>"isfalse" element.
>
>2) The ant version I am using is:
>
>[chetna@mango install]$ ant -version
>Ant version 1.4.1 compiled on July 31 2002
>[chetna@mango install]$
>
>Please let me know which ant version you guys are using. 
>
>Chetna  
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>are you planning your Web Server Security? Click here to get a FREE
>Thawte SSL guide and find the answers to all your  SSL security issues.
>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>  
>

[Gusdev-gusdev] Gus 3.0

[Chetna W. <ch...@ar...>]

Hi,

I am trying to do:

1) [chetna@mango install]$ build GUS install -append

ant -f /home/projects/install/build.xml install -Dproj=GUS
-DtargetDir=/home/gus_home -Dcomp= -DprojectsDir=/home/projects
-Dappend=true -logger org.apache.tools.ant.NoBannerLogger | grep ']'

BUILD FAILED

/home/projects/install/build.xml:64: Class
org.apache.tools.ant.taskdefs.condition.And doesn't support the nested
"isfalse" element.

2) The ant version I am using is:

[chetna@mango install]$ ant -version
Ant version 1.4.1 compiled on July 31 2002
[chetna@mango install]$

Please let me know which ant version you guys are using. 

Chetna  

[Gusdev-gusdev] GUS documentation site

[Steve F. <st...@pc...>]

folks-

i have set up the *beginnings* of a GUS documentation site:   
http://www.gusdb.org/documentation.html

if you have ideas or want to contribute documentation, let me know.

steve

[Gusdev-gusdev] GUS 3.0 schema creation scripts

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

I've tested the GUS 3.0 schema creation scripts and have tagged the
current release in CVS as 'schema30-code10' (i.e., GUS schema version
3.0, code version 1.0.)  Here's the install process in a nutshell:

 1. Install the GUS code as described on the gusdb.org web site
    (at <http://www.gusdb.org/BuildSystemSetup.html>)  During the
    installation the build system should tell you to create the
    properties file $GUS_HOME/config/schema.prop;  this file
    should be edited in order to customize the schema installation
    scripts to your site and Oracle database instance.

    (As an aside, if you don't want to place the Oracle SYS password
    in this file, you can instead choose to run the schema creation
    scripts manually, since only of the scripts must be run with
    SYS/DBA privileges.  In fact, now that I think of it, the script
    in question could be run by any user with the ability to create
    user accounts.  I'll put changing this on the to-do list.)

 2. Once the install is complete, cd to $GUS_HOME/schema/oracle
 3. Make sure that the Oracle utility 'sqlplus' is in your $PATH.
 4. Make sure that $GUS_HOME/bin is in your path and that you can
    execute the scripts therein.

    (Another aside; not all of the scripts have been updated to
    the new Perl package structure, but the only one we care
    about for this step is grantPermissions.pl and you can try
    running it on the command line--it should display a short
    usage message if successful.)

 5. Review $GUS_HOME/schema/oracle/create-db.sh to make sure that
    it's not going to do anything that you're unhappy with...
 6. Run ./create-db.sh (Or, if you're using the manual install method,
    run the commands contained in this file in the order given.)
 7. Check that all of the scripts and/or commands in create-db.sh
    ran successfully.

    (This step still needs to be automated.  For now you can either
    query the Oracle system tables to check that the correct number
    of uses/tables/etc. were created, or grep the .log files for the
    same information.  At the end of each .sql file is a line stating
    how many CREATE statements are in that file, which can be compared
    to the query or grep results.)

I won't be in the lab. tomorrow/today (Friday) but people in the lab.
should be able to reach me by mobile phone if there are any questions
or problems.

Jonathan

[Gusdev-gusdev] GUS Schema Feature Tracker

[Steve F. <st...@pc...>]

folks-

we have a new tracker for gus schema features.

see www.gusdb.org

steve

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

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

Arnaud-

Arnaud Kerhornou wrote:
> Can you clarify the structure of the Oracle instance ?
> As far as I understand GUS30 has 5 namespaces which actually are 
> implemented in Oracle as schema names or in other words as users.  To 

Yes, GUS30 currently has 5 namespaces (Core,SRes,DoTS,TESS,RAD3), each
of which is mapped to an Oracle user/schema of the same name.  Four of
the five namespaces (Core,SRes,DoTS,TESS) actually map to two Oracle
users, one of which is used to store the "version" tables for that
namespace.  In other words, the current mapping from GUS30 namespaces
to Oracle users/schemas looks like this:

Core  -> Core,CoreVer
SRes  -> SRes,SResVer
DoTS  -> DoTS,DoTSVer
TESS  -> TESS,TESSVer
RAD3  -> RAD3

Note that the capitalization *is* significant, because while Oracle is
case-insensitive (and, on occasion, just plain insensitive :), we do store
case-sensitive names in Core.DatabaseInfo.name and, furthermore, the Perl
and Java package names (which correspond to the GUS namespaces) are
case-sensitive too.

Given that each GUS instance maps to these 9 Oracle schemas, one question
is how to support multiple GUS instances running in the same Oracle
instance.  The schema names have to be distinct, so you would have to do
something like the following (where GUS1 and GUS2 can be considered
logical names for the two GUS instances):

GUS1 -> GUS1Core,GUS1CoreVer,GUS1SRes,GUS1SResVer,etc.
GUS2 -> GUS2Core,GUS2CoreVer,GUS2SRes,GUS2SResVer,etc.

I'm using a common prefix (GUS1 and GUS2, respectively) to group the schemata,
instead of a common suffix, for two reasons:

   1. Schemas named in this manner will be grouped correctly when sorted
      lexicographically (e.g., by an SQL ORDER BY clause)
   2. It's possible that some of the code assumes that the name of the
      "version" schema (e.g. DoTSVer) can be obtained simply by appending
      "Ver" to the main schema name (e.g. DoTS).

However, I should note that while the schema creation scripts were designed
to allow you to rename the Oracle schemas (e.g. you can rename Core to MyCore
and CoreVer to MyCoreVer), I don't think we can guarantee (yet) that the
rest of the code will support this.  If we ever want to support multiple
GUS instances in the same Oracle instance, this will have to be done, but
we're not there yet.

> access the different schemata there are two users, GUSrw, which has 
> read/write access to all of them, and GUSdevReadOnly, which has read 
> access only.
> Is that correct ?

That's how our copy of GUS is configured, but I haven't included these users
(GUSrw and GUSdevreadonly) in the schema creation scripts.  It's quite
possible that other sites will have other requirements, and so perhaps
this issue would be best addressed by providing a script that makes it
easy to create a new Oracle user with SELECT and/or UPDATE/INSERT/DELETE
permissions on a set of specified GUS namespaces.  I already have a script
that makes it easy to grant permissions on a set of tables, so perhaps
this, in addition to some documentation, will suffice.

Jonathan

[Gusdev-gusdev] oops... do a cvs update -d

[Steve F. <st...@pc...>]

folks,

after you do the cvs update i asked you to do in the last mail, also do 
this:

cd $PROJECT_HOME/install
cvs update -d  
(confirm that you got the config/ directory)

cd $PROJECT_HOME/GUS/Model
cvs update -d
(confirm that you got the schema/ and config/ directories)

sorry,
steve

[Gusdev-gusdev] GUS perl location

[Steve F. <st...@pc...>]

folks-

i have converted all perl executables that are in a bin/ directory to 
use #!@perlLocation@ instead of #!/usr/bin/perl, so now our perl code is 
"perl location independent"

you will get this by doing a cvs update.  (if you are not at CBIL, you 
won't get the latest CBIL project until i release it)

steve

[Gusdev-gusdev] build GUS: configuring gus !!!

[Steve F. <st...@pc...>]

folks-

the gus build system now allows us to configure the installation of gus.

the two configuration files so far are:
   $GUS_HOME/config/schema.prop   [to install the schema on an oracle 
instance... ie, for dba types]
   $GUS_HOME/config/install.prop      [discussed here]

the next time you run the build system, it will ask you to configure 
these files.

for those at CBIL:
    -follow the instructions provided by the build system.  
    -when it asks you to edit your config files, you can skip that step, 
because the defaults from the sample file will work for you.

for those elsewhere:
    - unless you are installing the schema, you can use the defaults 
from the sample file for schema.prop.
    - you may need to set the perlLocation property in install.prop: 
 this should be where your perl 5.6 is, if /usr/bin/perl isn't already that

steve

Re: [Gusdev-gusdev] schema change requests

[Steve F. <st...@pc...>]

OK, i have checked in the changes to the build system, so you can give 
it a try.

steve

Arnaud Kerhornou wrote:

> Hi Steve
>
> Why not setting everything right from the beginning ?
> Instead of using the feature request, another solution is to customize 
> a new tracker "schema request" in sourceforge ? We quite like this 
> idea, anyway let us know what you think about it ?
>
> cheers
> Arnaud
>
> steve fischer wrote:
>
>> yes, source forge allows us to set up trackers for bugs, features, etc.
>>
>> i had in mind to start out real simple with only one tracker... 
>> called bugs, to get the hang of things.  we can move to more trackers 
>> as needed.  or, if you are pretty clear that having one for bugs and 
>> one for features will be a good way to start, we can consider that too.
>>
>> steve
>>
>> Arnaud Kerhornou wrote:
>>
>>> Hi
>>>
>>> sourceforge also has feature requests. Would it make more sense to 
>>> submit schema changes as new features instead of bugs ?
>>>
>>> Arnaud
>>>
>>> steve fischer wrote:
>>>
>>>> Folks-
>>>>
>>>> we are gearing up to be a bit more formal about changing the schema 
>>>> mostly so that we can have distinct releases, which hopefully will 
>>>> be a spread out over time.
>>>>
>>>> so while we obviously need to continue our active dialogue in this 
>>>> mail group and other ways, i am hoping that when we actually 
>>>> resolve to make a schema change, we use our bug tracker (see 
>>>> www.gusdb.org) to record the request for the change.
>>>>
>>>> let me know how this works
>>>>
>>>> steve
>>>>
>
>
>
> -------------------------------------------------------
> 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
>
>

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

[Steve F. <st...@pc...>]

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
>
>
>  
>