gusdev-gusdev — Topics concerning GUS development

Re: [Gusdev-gusdev] LoadTaxon plugin

[pjm <pj...@sa...>]

Steve,

I tried your instructions and did a: `ga +meta --commit`
Arnaud has setup the DB so maybe he knows why - I needed to create a record in
the MACHINE table so I created the following SQL;

INSERT INTO MACHINE
       (MACHINE_ID,
        NAME,
        CPUS,
        MEMORY,
        MODIFICATION_DATE,
        USER_READ,
        USER_WRITE,
        GROUP_READ,
        GROUP_WRITE,
        OTHER_READ,
        OTHER_WRITE,
        ROW_USER_ID,
        ROW_GROUP_ID,
        ROW_PROJECT_ID,
        ROW_ALG_INVOCATION_ID)
VALUES (0, 'Fake_machine', 1, 1, SYSDATE, 1,1,1,1,1,1,1,1,1,1);

If this is useful I can create a new file called;
	GUS/Model/schema/oracle/core-machine-row.sql
or something. If I shouldn't, please let me know :)
Anyway, creating this record made the `ga +meta --commit` work.

Below is the error message I got when no MACHINE record existed.

pcs2b[pjm]63: ga +meta --commit
Reading properties from /nfs/team81/pjm/.gus.properties
DBD::Oracle::db do failed: ORA-01534: rollback segment 'BIGRBS0' doesn't exist
(DBD ERROR: OCIStmtExecute) at
/nfs/team81/pjm/GUS/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 148.
DBD::Oracle::db do failed: ORA-01534: rollback segment 'BIGRBS0' doesn't exist
(DBD ERROR: OCIStmtExecute) at
/nfs/team81/pjm/GUS/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 148.
DBD::Oracle::db do failed: ORA-01534: rollback segment 'BIGRBS0' doesn't exist
(DBD ERROR: OCIStmtExecute) at
/nfs/team81/pjm/GUS/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 148.
  <Core::Algorithm>
    <name>GA-Plugin</name>
    <description>GUS application framework for plugins</description>
    <Core::AlgorithmImplementation>
      <cvs_revision>1.25</cvs_revision>
      <cvs_tag> </cvs_tag>
      <executable>GUS::PluginMgr::GusApplication</executable>
      <description>update for GUS 3.0</description>
      <Core::AlgorithmInvocation>
        <start_time>sysdate</start_time>
        <end_time>sysdate</end_time>
        <machine_id>0</machine_id>
        <cpus_used>1</cpus_used>
        <result>meta</result>
      </Core::AlgorithmInvocation>
    </Core::AlgorithmImplementation>
  </Core::Algorithm>
DBD::Oracle::st execute failed: ORA-02291: integrity constraint
(CORE.ALGORITHMINVOCATION_FK04) violated - parent key not found (DBD ERROR:
OCIStmtExecute) at /nfs/team81/pjm/GUS/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line
134.

 DbiDbHandle:sqlExec: SQL ERROR!! involving
 
    INSERT INTO Core.AlgorithmInvocation (  end_time, row_user_id, user_write,
group_write, algorithm_implementation_id, row_project_id,
algorithm_invocation_id, group_read, row_group_id, result, other_read,
cpus_used, start_time, modification_date, user_read, row_alg_invocation_id,
other_write, machine_id )
    VALUES   (  sysdate, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, sysdate, SYSDATE, ?,
?, ?, ? ) 
 bindValues (1, 1, 1, 2, 1, 2, 1, 1, meta, 1, 1, 1, 1, 0, 0)



steve fischer wrote:
> 
> arnaud-
> 
> we have fixed this for now by using the oracle-specific 'sysdate' function.
> 
> try this:
>   - cd $PROJECT_HOME/GUS/PluginMgr/lib/perl
>   - cvs update (should bring in a new GusApplication.pm)
>   - build GUS install -append
>   - ga +meta --commit
> 
> steve
> 
> Jonathan Crabtree wrote:
> 
> >
> > steve fischer wrote:
> >
> >>
> >> Jonathan-  is there an easy way in perl to get an oracle compatible
> >> date?
> >>
> >
> > The problem is that you're relying on Oracle's implicit conversion
> > (from a string
> > to a DATE type) which will only work if the format of the provided
> > string matches
> > the default NLS_DATE_FORMAT of the Oracle instance in question.  We
> > should instead
> > use the TO_DATE function to do an explicit conversion from string ->
> > DATE.  Using
> > TO_DATE you can specify the format along with the string, so there's
> > no chance of
> > a mismatch.  Here's the man page for TO_DATE:
> >
> > <http://otn.oracle.com/docs/products/oracle9i/doc_library/901_doc/server.901/a90125/functions134.htm#1003595>
> >
> >
> > We probably should use something like this:
> >
> > TO_DATE('2002/12/6', 'YYYY/MM/DD')
> >
> > (assuming that the date is December 6th, not June 12th.)
> >
> > Jonathan
> >
> 
> -------------------------------------------------------
> 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] gus schema 3.0 is done

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

Hi,

Just wanted to let you know that the 3.0 schema is done now. Will be
looking for the 3.0 plugins and object layer matter.

Thanks
Chetna

Re: [Gusdev-gusdev] LoadTaxon plugin

[pjm <pj...@sa...>]

Steve, Jonathan,

Are there any plans to make DB specific code compartmentized? I know some SQL is
bound to be DB specific for performance or specific feature. Just wondered as
we'd love to give away GeneDB (and hence GUS) so others can have their own
installation. I guess you would too since you already have given it away :)

Paul.

steve fischer wrote:
> 
> arnaud-
> 
> we have fixed this for now by using the oracle-specific 'sysdate' function.
> 
> try this:
>   - cd $PROJECT_HOME/GUS/PluginMgr/lib/perl
>   - cvs update (should bring in a new GusApplication.pm)
>   - build GUS install -append
>   - ga +meta --commit
> 
> steve
> 
> Jonathan Crabtree wrote:
> 
> >
> > steve fischer wrote:
> >
> >>
> >> Jonathan-  is there an easy way in perl to get an oracle compatible
> >> date?
> >>
> >
> > The problem is that you're relying on Oracle's implicit conversion
> > (from a string
> > to a DATE type) which will only work if the format of the provided
> > string matches
> > the default NLS_DATE_FORMAT of the Oracle instance in question.  We
> > should instead
> > use the TO_DATE function to do an explicit conversion from string ->
> > DATE.  Using
> > TO_DATE you can specify the format along with the string, so there's
> > no chance of
> > a mismatch.  Here's the man page for TO_DATE:
> >
> > <http://otn.oracle.com/docs/products/oracle9i/doc_library/901_doc/server.901/a90125/functions134.htm#1003595>
> >
> >
> > We probably should use something like this:
> >
> > TO_DATE('2002/12/6', 'YYYY/MM/DD')
> >
> > (assuming that the date is December 6th, not June 12th.)
> >
> > Jonathan
> >
> 
> -------------------------------------------------------
> 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] GUS/Website

[steve f. <sfi...@pc...>]

folks-

i have created a new component of the GUS project: Website.  It houses 
the general pages for the gusdb.org site.

individual documentation pages (eg, how to setup the build system) 
remain in those projects, for now in project/component/doc

steve

Re: [Gusdev-gusdev] LoadTaxon plugin

[steve f. <sfi...@pc...>]

arnaud-

we have fixed this for now by using the oracle-specific 'sysdate' function.

try this:
  - cd $PROJECT_HOME/GUS/PluginMgr/lib/perl
  - cvs update (should bring in a new GusApplication.pm)
  - build GUS install -append
  - ga +meta --commit

steve

Jonathan Crabtree wrote:

>
> steve fischer wrote:
>
>>
>> Jonathan-  is there an easy way in perl to get an oracle compatible 
>> date?
>>
>
> The problem is that you're relying on Oracle's implicit conversion 
> (from a string
> to a DATE type) which will only work if the format of the provided 
> string matches
> the default NLS_DATE_FORMAT of the Oracle instance in question.  We 
> should instead
> use the TO_DATE function to do an explicit conversion from string -> 
> DATE.  Using
> TO_DATE you can specify the format along with the string, so there's 
> no chance of
> a mismatch.  Here's the man page for TO_DATE:
>
> <http://otn.oracle.com/docs/products/oracle9i/doc_library/901_doc/server.901/a90125/functions134.htm#1003595> 
>
>
> We probably should use something like this:
>
> TO_DATE('2002/12/6', 'YYYY/MM/DD')
>
> (assuming that the date is December 6th, not June 12th.)
>
> Jonathan
>

Re: [Gusdev-gusdev] LoadTaxon plugin

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

steve fischer wrote:
> 
> Jonathan-  is there an easy way in perl to get an oracle compatible date?
> 

The problem is that you're relying on Oracle's implicit conversion (from a string
to a DATE type) which will only work if the format of the provided string matches
the default NLS_DATE_FORMAT of the Oracle instance in question.  We should instead
use the TO_DATE function to do an explicit conversion from string -> DATE.  Using
TO_DATE you can specify the format along with the string, so there's no chance of
a mismatch.  Here's the man page for TO_DATE:

<http://otn.oracle.com/docs/products/oracle9i/doc_library/901_doc/server.901/a90125/functions134.htm#1003595>

We probably should use something like this:

TO_DATE('2002/12/6', 'YYYY/MM/DD')

(assuming that the date is December 6th, not June 12th.)

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115

Re: [Gusdev-gusdev] LoadTaxon plugin

[steve f. <sfi...@pc...>]

i know where they are coming from... and, yes they are hard coded in 
GusApplication.pm.

Jonathan-  is there an easy way in perl to get an oracle compatible date?

steve

Jonathan Crabtree wrote:

>
>
> Arnaud Kerhornou wrote:
>
>>    INSERT INTO Core.AlgorithmInvocation (  end_time, row_user_id, 
>> user_write, group_write, algorithm_implementation_id, row_project_id, 
>> algorithm_invocation_id, group_read, row_group_id, result, 
>> other_read, cpus_used, start_time, modification_date, user_read, 
>> row_alg_invocation_id, other_write, machine_id )
>>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, 
>> ?, ? )
>> bindValues (2002/12/6, 1, 1, 1, 2, 1, 2, 1, 1, meta, 1, 1, 2002/12/6, 
>> 1, 1, 0, 0)
>> <---------------------------------
>>
>
> Arnaud-
>
> The error you got was "literal does not match format string", which I 
> think
> means that the two dates in the above INSERT command ("2002/12/6" for 
> end_time
> and "2002/12/6" for start_time) do not conform to the default 
> NLS_DATE_FORMAT
> of your Oracle instance.  I don't know how (or where) these date 
> strings are
> being generated, but they appear to be incorrect.  I don't think 
> they're being
> hard-coded, because I don't think those dates would work in our system 
> either.
> We use the following default date format:
>
> nls_date_format = "YYYY-MM-DD HH24:MI:SS"
>
> Anyway, hope this helps in the debugging; Steve and Jonathan Schug are 
> probably
> the most familiar with ga, so I'll let them take it from here.
>
> Jonathan
>

Re: [Gusdev-gusdev] LoadTaxon plugin

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

Arnaud Kerhornou wrote:
>    INSERT INTO Core.AlgorithmInvocation (  end_time, row_user_id, 
> user_write, group_write, algorithm_implementation_id, row_project_id, 
> algorithm_invocation_id, group_read, row_group_id, result, other_read, 
> cpus_used, start_time, modification_date, user_read, 
> row_alg_invocation_id, other_write, machine_id )
>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ? )
> bindValues (2002/12/6, 1, 1, 1, 2, 1, 2, 1, 1, meta, 1, 1, 2002/12/6, 1, 
> 1, 0, 0)
> <---------------------------------
> 

Arnaud-

The error you got was "literal does not match format string", which I think
means that the two dates in the above INSERT command ("2002/12/6" for end_time
and "2002/12/6" for start_time) do not conform to the default NLS_DATE_FORMAT
of your Oracle instance.  I don't know how (or where) these date strings are
being generated, but they appear to be incorrect.  I don't think they're being
hard-coded, because I don't think those dates would work in our system either.
We use the following default date format:

nls_date_format = "YYYY-MM-DD HH24:MI:SS"

Anyway, hope this helps in the debugging; Steve and Jonathan Schug are probably
the most familiar with ga, so I'll let them take it from here.

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115

Re: [Gusdev-gusdev] LoadTaxon plugin

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

Hi

I've tried it and here what I got:
----------------------->
pcs2g[axk]527: ga +meta --commit
Reading properties from /nfs/team81/axk/.gus.properties
  <Core::Algorithm>
    <name>GA-Plugin</name>
    <description>GUS application framework for plugins</description>
    <Core::AlgorithmImplementation>
      <cvs_revision>1.23</cvs_revision>
      <cvs_tag> </cvs_tag>
      <executable>GUS::PluginMgr::GusApplication</executable>
      <description>update for GUS 3.0</description>
      <Core::AlgorithmInvocation>
        <start_time>2002/12/6</start_time>
        <end_time>2002/12/6</end_time>
        <machine_id>0</machine_id>
        <cpus_used>1</cpus_used>
        <result>meta</result>
      </Core::AlgorithmInvocation>
    </Core::AlgorithmImplementation>
  </Core::Algorithm>
DBD::Oracle::st execute failed: ORA-01861: literal does not match format 
string (DBD ERROR: OCIStmtExecute) at 
/nfs/team81/axk/projects/gus/gus.deployment/lib/perl/GUS/ObjRelP/DbiDbHandle.pm 
line 134.

 DbiDbHandle:sqlExec: SQL ERROR!! involving
 
    INSERT INTO Core.AlgorithmInvocation (  end_time, row_user_id, 
user_write, group_write, algorithm_implementation_id, row_project_id, 
algorithm_invocation_id, group_read, row_group_id, result, other_read, 
cpus_used, start_time, modification_date, user_read, 
row_alg_invocation_id, other_write, machine_id )
    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, 
? )
 bindValues (2002/12/6, 1, 1, 1, 2, 1, 2, 1, 1, meta, 1, 1, 2002/12/6, 
1, 1, 0, 0)
<---------------------------------

Does it work for you guys?
Arnaud

steve fischer wrote:

> yep.   (we *will* be documenting all this)
>
> first do this:
>
> ga +meta --commit
>
> steve
>
> Arnaud Kerhornou wrote:
>
>> I've tried this:
>>
>> pcs2g[axk]499: ga +create GUS::PluginMgr::GusApplication --commit
>> Reading properties from /nfs/team81/axk/.gus.properties
>> Thu Feb 20 16:28:18 2003        ERROR-IMP       No 
>> Core.AlgorithmImplementation found for GUS::PluginMgr::GusApplication
>> Thu Feb 20 16:28:18 2003        ERROR-IMP       Please use 'ga 
>> +create GUS::PluginMgr::GusApplication --commit'
>>
>> Basically prior to do the plugins registration this way, 
>> AlgorithmImplementation needs one entry, GUS::PluginMgr::GusApplication.
>>
>> Ar
>>

Re: [Gusdev-gusdev] grantPermissions.pl - dbport parameter

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

On Thu, 20 Feb 2003, Arnaud Kerhornou wrote:
> Would it be possible to add an extra parameter, dbPort, to the script
> grantPermissions.pl and pass it to GUS::DBAdmin::Database constructor?

Arnaud-

This should be fixed now.  I also had to update
DBAdmin/lib/perl/Database.pm due to a bug in the code that was
constructing the DBI_DSN string.

Jonathan

Re: [Gusdev-gusdev] DBI 1.28

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

Chetna-

On Thu, 20 Feb 2003, Chetna Warade wrote:
> I was wondering from which site to get the perl DBI 1.28 module. I thought
> it should be obvious to reach there but I am not able to find it. Is ti
> possible for you guys to tell me where to look for the DBI 1.28 module

Depending on what operating system you're running, you may be able to
download modules either in the form of packages (for example, RedHat
Linux supports this through 'rpm') or as gzipped tar files.  We use
RedHat but I installed both DBI and DBD::Oracle without using .rpm files.
It's often easier to get the latest versions of software in .tar.gz, which
is the main reason for doing this.

Anyway, the best place to look for any Perl module is the site CPAN.org;
all kinds of Perl modules are indexed there, and there's a good search
interface.  Here are the DBI and DBD modules in .tar.gz form:

http://www.cpan.org/modules/by-module/DBI/
http://www.cpan.org/modules/by-module/DBD/

Jonathan

[Gusdev-gusdev] DBI 1.28

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

Hi,

I was wondering from which site to get the perl DBI 1.28 module. I thought
it should be obvious to reach there but I am not able to find it. Is ti
possible for you guys to tell me where to look for the DBI 1.28 module 

chetna

Re: [Gusdev-gusdev] grantP ...

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

Chetna-

> I'm getting the same error msg for the test pl.
> 
> [chetna@mango chetna]$ ./test.pl
> DBI 1.2 required--this is only version 1.18
> (/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm) at ./test.pl line 3
> Compilation failed in require at ./test.pl line 3.
> BEGIN failed--compilation aborted at ./test.pl line 3.
> [chetna@mango chetna]$
> 
> I am getting DBI-2.28 for mango and the DBD-Oracle that I use is 1.12

OK, sounds good; once you've installed the newer version of DBI I think
the test script should work.  And once the test script works, the GUS
scripts should also be OK.  Let me know if this is not the case,

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115

Re: [Gusdev-gusdev] grantP ...

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

Hi,

Thanks for the mail.
I'm getting the same error msg for the test pl.

[chetna@mango chetna]$ ./test.pl
DBI 1.2 required--this is only version 1.18
(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm) at ./test.pl line 3
Compilation failed in require at ./test.pl line 3.
BEGIN failed--compilation aborted at ./test.pl line 3.
[chetna@mango chetna]$

I am getting DBI-2.28 for mango and the DBD-Oracle that I use is 1.12

chetna



> I don't believe that our code requires a particularly recent version
> of DBI, so my guess is that the incompatibility is between your DBD::Oracle
> and DBI.  Can you try creating the following trivial Perl script and tell me
> whether it will run:
> 
> -----------------------------begin test.pl---------------------------
> #!/usr/bin/perl
> use DBI;
> use DBD::Oracle;
> 
> print "Test successful!\n";
> 
> -----------------------------end test.pl-----------------------------
> 
> If you get the same error message from this test script then it's likely
> that your copy of DBD::Oracle is not compatible with your copy of DBI.
> 
> > I have 1.18 here which version do you guys recommend.
> 
> We're using DBD-Oracle-1.12 and DBI-1.28 on our test machine, and so I know
> that these versions are definitely compatible.  Let me know whether the above
> test works.
> 
> Jonathan
> 
> -- 
> Jonathan Crabtree
> Center for Bioinformatics, University of Pennsylvania
> 1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
> 215-573-3115
> 
> 

Re: [Gusdev-gusdev] grantP ...

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

Hi Chetna-

Chetna Warade wrote:
> There is a conflict with the DBI version:

I don't believe that our code requires a particularly recent version
of DBI, so my guess is that the incompatibility is between your DBD::Oracle
and DBI.  Can you try creating the following trivial Perl script and tell me
whether it will run:

-----------------------------begin test.pl---------------------------
#!/usr/bin/perl
use DBI;
use DBD::Oracle;

print "Test successful!\n";

-----------------------------end test.pl-----------------------------

If you get the same error message from this test script then it's likely
that your copy of DBD::Oracle is not compatible with your copy of DBI.

> I have 1.18 here which version do you guys recommend.

We're using DBD-Oracle-1.12 and DBI-1.28 on our test machine, and so I know
that these versions are definitely compatible.  Let me know whether the above
test works.

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115

[Gusdev-gusdev] grantP ...

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

Hi,

There is a conflict with the DBI version:

[chetna@mango chetna]$ grantPermissions.pl
DBI 1.2 required--this is only version 1.18
(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm) at
/home/gus_home/lib/perl/GUS/DBAdmin/Util.pm line 18 Compilation failed in
require at
/home/gus_home/lib/perl/GUS/DBAdmin/Util.pm line 18.
BEGIN failed--compilation aborted at
/home/gus_home/lib/perl/GUS/DBAdmin/Util.pm line 18.
Compilation failed in require at
/home/gus_home/lib/perl/GUS/DBAdmin/Tablespace.pm line 17.
BEGIN failed--compilation aborted at
/home/gus_home/lib/perl/GUS/DBAdmin/Tablespace.pm line 17.
Compilation failed in require at
/home/gus_home/lib/perl/GUS/DBAdmin/Database.pm line 17.
BEGIN failed--compilation aborted at
/home/gus_home/lib/perl/GUS/DBAdmin/Database.pm line 17.
Compilation failed in require 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 have 1.18 here which version do you guys recommend.

Chetna

Re: [Gusdev-gusdev] LoadTaxon plugin

[steve f. <sfi...@pc...>]

yep.   (we *will* be documenting all this)

first do this:

ga +meta --commit

steve

Arnaud Kerhornou wrote:

> I've tried this:
>
> pcs2g[axk]499: ga +create GUS::PluginMgr::GusApplication --commit
> Reading properties from /nfs/team81/axk/.gus.properties
> Thu Feb 20 16:28:18 2003        ERROR-IMP       No 
> Core.AlgorithmImplementation found for GUS::PluginMgr::GusApplication
> Thu Feb 20 16:28:18 2003        ERROR-IMP       Please use 'ga +create 
> GUS::PluginMgr::GusApplication --commit'
>
> Basically prior to do the plugins registration this way, 
> AlgorithmImplementation needs one entry, GUS::PluginMgr::GusApplication.
>
> Ar
>
> Jonathan Crabtree wrote:
>
>>
>> Arnaud-
>>
>>> Is the Core.AlgorithmImplementation entries population part of the 
>>> build process or is it an extra step?
>>
>>
>>
>> It is not currently part of the build process; if you look through 
>> the error
>> message that the plugin generated, it tells you the command to run in 
>> order
>> to register it in the database (i.e. AlgorithmImplementation):
>>
>> > Thu Feb 20 12:43:40 2003        ERROR-IMP       Please use 'ga +create
>> > GUS::Common::Plugin::LoadTaxon --commit'
>>
>> Obviously, this *should* be part of the build process, but I think 
>> it's not a
>> bad thing that it isn't (at this stage) because we still haven't 
>> formalized
>> our procedure for testing plugins (both in terms of 3.x schema 
>> compliance and
>> also in terms of bug testing/automatic regression testing.)  As 
>> plugins are
>> brought into reasonable compliance with the new system perhaps we can 
>> add them
>> to the list of plugins that are automatically registered in the 
>> database at
>> build time.  Steve, what do you think about this idea?  Is this the 
>> right
>> mechanism to use or should we have another way to indicate that 
>> plugins have
>> not yet been tested/validated?
>>
>> Jonathan
>>
>
>
>
> -------------------------------------------------------
> 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
>
>

Re: [Gusdev-gusdev] LoadTaxon plugin

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

I've tried this:

pcs2g[axk]499: ga +create GUS::PluginMgr::GusApplication --commit
Reading properties from /nfs/team81/axk/.gus.properties
Thu Feb 20 16:28:18 2003        ERROR-IMP       No 
Core.AlgorithmImplementation found for GUS::PluginMgr::GusApplication
Thu Feb 20 16:28:18 2003        ERROR-IMP       Please use 'ga +create 
GUS::PluginMgr::GusApplication --commit'

Basically prior to do the plugins registration this way, 
AlgorithmImplementation needs one entry, GUS::PluginMgr::GusApplication.

Ar

Jonathan Crabtree wrote:

>
> Arnaud-
>
>> Is the Core.AlgorithmImplementation entries population part of the 
>> build process or is it an extra step?
>
>
> It is not currently part of the build process; if you look through the 
> error
> message that the plugin generated, it tells you the command to run in 
> order
> to register it in the database (i.e. AlgorithmImplementation):
>
> > Thu Feb 20 12:43:40 2003        ERROR-IMP       Please use 'ga +create
> > GUS::Common::Plugin::LoadTaxon --commit'
>
> Obviously, this *should* be part of the build process, but I think 
> it's not a
> bad thing that it isn't (at this stage) because we still haven't 
> formalized
> our procedure for testing plugins (both in terms of 3.x schema 
> compliance and
> also in terms of bug testing/automatic regression testing.)  As 
> plugins are
> brought into reasonable compliance with the new system perhaps we can 
> add them
> to the list of plugins that are automatically registered in the 
> database at
> build time.  Steve, what do you think about this idea?  Is this the right
> mechanism to use or should we have another way to indicate that 
> plugins have
> not yet been tested/validated?
>
> Jonathan
>

Re: [Gusdev-gusdev] LoadTaxon plugin

[steve f. <sfi...@pc...>]

yes, this sounds reasonable.  

basically, we are in a period of transition.  i think the goal should be 
that any plugin that is in the public CVS is registered, and in compliance.

steve

Jonathan Crabtree wrote:

>
> Arnaud-
>
>> Is the Core.AlgorithmImplementation entries population part of the 
>> build process or is it an extra step?
>
>
> It is not currently part of the build process; if you look through the 
> error
> message that the plugin generated, it tells you the command to run in 
> order
> to register it in the database (i.e. AlgorithmImplementation):
>
> > Thu Feb 20 12:43:40 2003        ERROR-IMP       Please use 'ga +create
> > GUS::Common::Plugin::LoadTaxon --commit'
>
> Obviously, this *should* be part of the build process, but I think 
> it's not a
> bad thing that it isn't (at this stage) because we still haven't 
> formalized
> our procedure for testing plugins (both in terms of 3.x schema 
> compliance and
> also in terms of bug testing/automatic regression testing.)  As 
> plugins are
> brought into reasonable compliance with the new system perhaps we can 
> add them
> to the list of plugins that are automatically registered in the 
> database at
> build time.  Steve, what do you think about this idea?  Is this the right
> mechanism to use or should we have another way to indicate that 
> plugins have
> not yet been tested/validated?
>
> Jonathan
>

Re: [Gusdev-gusdev] grantPermissions.pl

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

Hi Chetna-

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. 

That's why I recommended (I think!) testing grantPermissions.pl and sqlplus
*before* running the create-db.sh script.  I'm writing up the schema install
documentation later today, so I'll be sure to include a warning about this.

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115

Re: [Gusdev-gusdev] LoadTaxon plugin

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

Arnaud-

> Is the Core.AlgorithmImplementation entries population part of the build 
> process or is it an extra step?

It is not currently part of the build process; if you look through the error
message that the plugin generated, it tells you the command to run in order
to register it in the database (i.e. AlgorithmImplementation):

 > Thu Feb 20 12:43:40 2003        ERROR-IMP       Please use 'ga +create
 > GUS::Common::Plugin::LoadTaxon --commit'

Obviously, this *should* be part of the build process, but I think it's not a
bad thing that it isn't (at this stage) because we still haven't formalized
our procedure for testing plugins (both in terms of 3.x schema compliance and
also in terms of bug testing/automatic regression testing.)  As plugins are
brought into reasonable compliance with the new system perhaps we can add them
to the list of plugins that are automatically registered in the database at
build time.  Steve, what do you think about this idea?  Is this the right
mechanism to use or should we have another way to indicate that plugins have
not yet been tested/validated?

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115

Re: [Gusdev-gusdev] grantPermissions.pl - dbport parameter

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

steve fischer wrote:
> Arnaud-
> 
> i think you can provide this in your .gus.properties file:
> 
> it has this proprerty:
> dbiDsn=dbi:Oracle:host=erebus.pcbi.upenn.edu;sid=gusdev

That's true, but it doesn't fix the problem Arnaud mentioned, which
is that grantPermissions.pl is constructing the DBI DSN string itself
(using the Database.pm module) and is not giving the user the chance
to specify a non-standard port for the Oracle server.  I think that
what I want to do here is to fix grantPermissions.pl as Arnaud described
(rather than force it to use the standardized dbiDsn).  The reason for
this is that we can then use grantPermissions.pl on an Oracle instance
that differs from the one specified in the properties file.  I think
this is a reasonable thing to do for the DBA utilities, not all of which
are as tightly tied to GUS as, for example, the Perl object layer and
other parts of the system.

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115

Re: [Gusdev-gusdev] grantPermissions.pl - dbport parameter

[steve f. <sfi...@pc...>]

Arnaud-

i think you can provide this in your .gus.properties file:

it has this proprerty:
dbiDsn=dbi:Oracle:host=erebus.pcbi.upenn.edu;sid=gusdev

steve


Arnaud Kerhornou wrote:

>  Hi
>
> Would it be possible to add an extra parameter, dbPort, to the script 
> grantPermissions.pl and pass it to GUS::DBAdmin::Database constructor?
>
> The connection fails unless we give a port number. Here the dbi_dsn 
> which works for us : 'dbi:Oracle:host=ocs3;sid=tpat;port=1532'
>
> Thanks
> Arnaud
>

[Gusdev-gusdev] LoadTaxon plugin

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

Hi

I've started loading controlled vocabulary tables. I've downloaded Taxonomy data and had a go with the LoadTaxon plugin.

Here the output:

--------------------->
pcs2g[axk]492: ./bin/ga GUS::Common::Plugin::LoadTaxon --gencode=/nfs/pathsoft/databases/NCBI/gc.prt --verbose
Reading properties from /nfs/team81/axk/.gus.properties

prepareAndExecute:     SELECT *
      FROM Core.AlgorithmImplementation
     WHERE executable = 'GUS::Common::Plugin::LoadTaxon'
       AND cvs_revision    = '1.20'

prepareAndExecute: select * from core.algorithmimplementation where executable = 'GUS::Common::Plugin::LoadTaxon' 
Thu Feb 20 12:43:40 2003        ERROR-IMP       No Core.AlgorithmImplementation found for GUS::Common::Plugin::LoadTaxon
Thu Feb 20 12:43:40 2003        ERROR-IMP       Please use 'ga +create GUS::Common::Plugin::LoadTaxon --commit'
Issuing rollback() for database handle being DESTROY'd without explicit disconnect().
<---------------------

Is the Core.AlgorithmImplementation entries population part of the build process or is it an extra step?

cheers
Arnaud

[Gusdev-gusdev] grantPermissions.pl - dbport parameter

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

  Hi

Would it be possible to add an extra parameter, dbPort, to the script 
grantPermissions.pl and pass it to GUS::DBAdmin::Database constructor?

The connection fails unless we give a port number. Here the dbi_dsn 
which works for us : 'dbi:Oracle:host=ocs3;sid=tpat;port=1532'

Thanks
Arnaud

-- 
Arnaud Kerhornou

The Wellcome Trust Sanger Institute
The Pathogen Sequencing Unit
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SA, UK
Work: +44 (0) 1223 494955
Fax:  +44 (0) 1223 494919