Menu
▾
▴
gusdev-gusdev
|
From: Arnaud K. <ax...@sa...> - 2003-02-20 12:51:12
|
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
|
|
From: Jonathan C. <cra...@pc...> - 2003-02-20 15:16:39
|
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 |
|
From: steve f. <sfi...@pc...> - 2003-02-20 15:34:51
|
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 > |
|
From: Arnaud K. <ax...@sa...> - 2003-02-20 16:41:23
|
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 > |
|
From: steve f. <sfi...@pc...> - 2003-02-20 17:18:48
|
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 > > |
|
From: Arnaud K. <ax...@sa...> - 2003-02-21 16:09:53
|
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
>>
|
|
From: Jonathan C. <cra...@pc...> - 2003-02-21 17:20:49
|
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
|
|
From: steve f. <sfi...@pc...> - 2003-02-21 18:19:24
|
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
>
|
|
From: Jonathan C. <cra...@pc...> - 2003-02-21 18:36:10
|
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 |
|
From: steve f. <sfi...@pc...> - 2003-02-21 19:09:56
|
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 > |
|
From: pjm <pj...@sa...> - 2003-02-21 20:46:56
|
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 |
|
From: Jonathan C. <cra...@sn...> - 2003-02-25 13:45:00
|
Paul- On Fri, 21 Feb 2003, pjm wrote: > 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 :) Yes, we definitely want to separate the dbms-specific code from the rest in a clean and understandable way. However, we're definitely not there yet. When we made the switch from Sybase to Oracle a couple of years ago we did a fairly good job of isolating the dbms-specific code, at least in the Perl object layer, which is where most of it appears. But since then there's no question that we've been careless in allowing dbms-specific code to creep back in, and there's also the related issue that when *new* dbms-specific code was required, we would implement it only for Oracle, not for both Oracle and Sybase. Anyway, the short answer is that our eventual plan is to be able to support at least one other DBMS in addition to Oracle, and we're planning to do this for either MySQL or PostgreSQL, since both are open source and freely available. Jonathan |
|
From: pjm <pj...@sa...> - 2003-02-21 21:48:19
|
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
|
|
From: Jonathan C. <cra...@sn...> - 2003-02-25 13:49:41
|
Paul- On Fri, 21 Feb 2003, pjm wrote: > 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. I think we should just make the machine_id column nullable in core.AlgorithmInvocation; I noticed this problem with the reference to core.Machine a few weeks ago and I thought I'd changed the schema before putting it in CVS, but apparently not. This will go into the next release, and I'll start putting together the migration script today, since quite a few schema changes have been made since the initial 3.0 release. Jonathan |
|
From: Chetna W. <ch...@ar...> - 2003-02-24 18:10:54
|
Hi, I trying to figure the directory structure that I need to maintain for gus 3.0 perl object layer. I have downloaded the latest GUS tar from sanger cvs. Basically I am looking for plugin installation instruction. Let me know if I am wrong. Chetna |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X