gusdev-gusdev Mailing List for Genomic Unified Schema Development (Page 61)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi

Does anyone know how I can connect SRes::BibliographicReference to 
NAFeature views ?

cheers
Arnaud

I've changed the docs so the line breaks are no longer present.
Thanks for letting us know.

On 24 Jul 2004, at 21:07, Pablo N. Mendes wrote:

> Hello all,
> this is just to let you know that the plug-in UpdateGusFromXML is
> crashing when trying to load DoTS::SequenceType bootstrap data  
> published
> on Wiki.
>
> The error message has:
>
> Illegal className 'description' (not in schema::table form) at
> /usr/local/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 696
>
> GUS::ObjRelP::DbiDatabase::getFullTableClassName('GUS::ObjRelP:: 
> DbiDatabase=HASH(0x8841c70)','description') called at  
> /usr/local/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 261
> (...)
>
> I found that if I eliminate the line brake from this part of the XML:
>   <description>\n
>     mRNA sequence predicted by an algorithm from genomic DNA\n
>   </description>\n
>
> And input to the plugin like this:
>
>   <description>mRNA sequence predicted by an algorithm from genomic
> DNA</description>\n
>
> everything goes well. The plugin seems to be reading a "tag + line
> brake" (e.g. "<description>\n") as a "new class", instead of new
> attribute of the current class.
>
> Best regards,
> Pablo
> -- 
> -----------------------------
> Pablo N. Mendes
> Research Scholar
> Department of Molecular Biology (DBBM)
> Fiocruz
> Rio de Janeiro, RJ
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Hello all,
this is just to let you know that the plug-in UpdateGusFromXML is
crashing when trying to load DoTS::SequenceType bootstrap data published
on Wiki.

The error message has:

Illegal className 'description' (not in schema::table form) at
/usr/local/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 696

GUS::ObjRelP::DbiDatabase::getFullTableClassName('GUS::ObjRelP::DbiDatabase=HASH(0x8841c70)','description') called at /usr/local/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 261
(...)

I found that if I eliminate the line brake from this part of the XML:
  <description>\n
    mRNA sequence predicted by an algorithm from genomic DNA\n
  </description>\n

And input to the plugin like this:

  <description>mRNA sequence predicted by an algorithm from genomic
DNA</description>\n

everything goes well. The plugin seems to be reading a "tag + line
brake" (e.g. "<description>\n") as a "new class", instead of new
attribute of the current class.

Best regards,
Pablo
-- 
-----------------------------
Pablo N. Mendes
Research Scholar
Department of Molecular Biology (DBBM)
Fiocruz
Rio de Janeiro, RJ

We had the same problem last month here. We posted comments on this on
the Wiki.

I wrote a script to reset all sequences based on the primary key's max
value. It's available at:
http://mango.ctegd.uga.edu/jkissingLab/download/gus_oracle_seqfix.pl.gz

Best regards,
Pablo

On Thu, 2004-07-22 at 15:52, Arnaud Kerhornou wrote:
> John Iodice wrote:
> 
> >Maybe the cause was a twofold problem:
> >
> >1. The select against the sequence.nextval failed because of database
> >permission problems, and
> >2. The application is coded to populate the new primary key with
> >maxval+1 in case of (1)
> >
> >I have seen this series of events while using plugins to populate GUS
> >tables.
> >
> >It seems that you could test (1) by starting up sqlplus as the user that
> >ran the "ga" and typing "select <sequence-name>.nextval from dual".
> >
> >  
> >
> we did this and we noticed that any sequence.nextval returned 1. I think 
> that's why we got the same message than Thomas, "DBD::Oracle::st execute 
> failed: ORA-00001: unique constraint (CORE.PK_ALGORITHMIMPLEMENTATION) 
> violated". We didn't get any permission issues.
> 
> To fix this we have reset the sequences to a high number to make sure 
> they don't clash with already existing PK values. Well it's a temporary 
> hack !
> 
> Arnaud
> 
> >On Thu, 2004-07-22 at 15:08, Arnaud Kerhornou wrote:
> >  
> >
> >>Hi
> >>
> >>The same problem ocurred to me recently. When we checked the Oracle 
> >>sequences, they were all set to 1 though there were some rows in some 
> >>tables. I don't know why that has happened.
> >>
> >>Does anyone have an idea why the sequences could be reset to 1 ?
> >>
> >>Arnaud
> >>
> >>Thomas Otto wrote:
> >>
> >>    
> >>
> >>>Folks,
> >>>
> >>>I found my error:
> >>>The problem was, that the sequences of the tables in the oracle didn't 
> >>>display the realy primarykey number. I do not know why, but I will 
> >>>have an eye on it.
> >>>I modify the 'lastnumber', and know it seems to work out.
> >>>
> >>>Cheers,
> >>>Thomas
> >>>Thomas Otto wrote:
> >>>
> >>>      
> >>>
> >>>>Hi,
> >>>>
> >>>>I did an update via cvs, rebuild the stuff, worked more or less fine.
> >>>>
> >>>>But this the ga wanted to be registered another time:
> >>>>USER ERROR: GUS::PluginMgr::GusApplication revision 1.52 has not been 
> >>>>registered.
> >>>>Please use 'ga +meta --commit'
> >>>>
> >>>>The error of this command see below. There is a conflict of the 
> >>>>primary key...
> >>>>So I changed the cvs version and the MD5 checksum in the table.
> >>>>
> >>>>But I have to do this for all the plugins - no fun...
> >>>>
> >>>>Who can help me?
> >>>>
> >>>>Thomas
> >>>>
> >>>>
> >>>>ERROR: of ga + meta --commit
> >>>>DBD::Oracle::st execute failed: ORA-00001: unique constraint 
> >>>>(CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: 
> >>>>OCIStmtExecute) at 
> >>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
> >>>>
> >>>>SQL ERROR!! involving
> >>>>
> >>>>   INSERT INTO Core.AlgorithmImplementation (  other_read, 
> >>>>group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
> >>>>user_read, row_user_id, description, algorithm_implementation_id, 
> >>>>other_write, modification_date, row_project_id, 
> >>>>row_alg_invocation_id, executable_md5, executable, row_group_id, 
> >>>>user_write )
> >>>>   VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
> >>>>?, ? ) Values: 1, 1, 1.52, 2, 1,  , 1, 1, update for GUS 3.0, 22, 0, 
> >>>>1, 1, c1212c2753960e177d29b40d5a313f59, 
> >>>>GUS::PluginMgr::GusApplication, 1, 1 at 
> >>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
> >>>>       
> >>>>GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','\x{a} 
> >>>>SQL ERROR!! involving\x{a} \x{a}    INSERT INTO 
> >>>>Core.AlgorithmImple...') called at 
> >>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 148
> >>>>       
> >>>>GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','GUS::ObjRelP::DbiDbHandle::st=HASH(0x87d1e30)','ARRAY(0x87d1ef0)','\x{a}    
> >>>>INSERT INTO Core.AlgorithmImplementation (  other_read, ...') called 
> >>>>at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681
> >>>>       
> >>>>GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','HASH(0x86f1b28)') 
> >>>>called at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628
> >>>>       
> >>>>GUS::ObjRelP::DbiRow::insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)') 
> >>>>called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677
> >>>>       
> >>>>GUS::Model::GusRow::submit('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','undef',1) 
> >>>>called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1764
> >>>>       
> >>>>GUS::Model::GusRow::submitChildrenInClass('GUS::Model::Core::Algorithm=HASH(0x8690ff8)','GUS::Model::Core::AlgorithmImplementation') 
> >>>>called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1745
> >>>>       
> >>>>GUS::Model::GusRow::submitAllChildren('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
> >>>>called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684
> >>>>       
> >>>>GUS::Model::GusRow::submit('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
> >>>>called at 
> >>>>/home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 361
> >>>>       
> >>>>GUS::PluginMgr::GusApplication::doMajorMode_Meta('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
> >>>>called at 
> >>>>/home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 289
> >>>>       
> >>>>GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
> >>>>called at 
> >>>>/home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 198
> >>>>       
> >>>>GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','ARRAY(0x8060684)') 
> >>>>called at /home/oracle/gus_home/bin/ga line 11
> >>>>
> >>>>
> >>>>
> >>>>ERROR of Submitrow:
> >>>>DBD::Oracle::st execute failed: ORA-00001: unique constraint 
> >>>>(CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: 
> >>>>OCIStmtExecute) at 
> >>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
> >>>>
> >>>>SQL ERROR!! involving
> >>>>
> >>>>   INSERT INTO Core.AlgorithmImplementation (  other_read, 
> >>>>group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
> >>>>user_read, row_user_id, description, algorithm_implementation_id, 
> >>>>other_write, modification_date, row_project_id, 
> >>>>row_alg_invocation_id, executable_md5, executable, row_group_id, 
> >>>>user_write )
> >>>>   VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
> >>>>?, ? ) Values: 1, 1, 1.9, 3, 1,  , 1, 1, make consistent with GUS 
> >>>>3.0, 24, 0, 1, 1, 60470c8cf30c7cea218fcbbb48840d97, 
> >>>>GUS::Common::Plugin::SubmitRow, 1, 1 at 
> >>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
> >>>>
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.Net email is sponsored by BEA Weblogic Workshop
> >>>>FREE Java Enterprise J2EE developer tools!
> >>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
> >>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> >>>>_______________________________________________
> >>>>Gusdev-gusdev mailing list
> >>>>Gus...@li...
> >>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> >>>>
> >>>>        
> >>>>
> >>>
> >>>-------------------------------------------------------
> >>>This SF.Net email is sponsored by BEA Weblogic Workshop
> >>>FREE Java Enterprise J2EE developer tools!
> >>>Get your free copy of BEA WebLogic Workshop 8.1 today.
> >>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> >>>_______________________________________________
> >>>Gusdev-gusdev mailing list
> >>>Gus...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> >>>
> >>>      
> >>>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by BEA Weblogic Workshop
> >>FREE Java Enterprise J2EE developer tools!
> >>Get your free copy of BEA WebLogic Workshop 8.1 today.
> >>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> >>_______________________________________________
> >>Gusdev-gusdev mailing list
> >>Gus...@li...
> >>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> >>    
> >>
> >
> >  
> >
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
-- 
-----------------------------
Pablo Nascimento Mendes
Research Scholar
Kissinger Lab
Department of Genetics
University of Georgia
C210 Life Sciences Bldg.
Athens, Georgia 30602
Phone:706 542-1447
E-mail: pa...@ug...

John Iodice wrote:

>Maybe the cause was a twofold problem:
>
>1. The select against the sequence.nextval failed because of database
>permission problems, and
>2. The application is coded to populate the new primary key with
>maxval+1 in case of (1)
>
>I have seen this series of events while using plugins to populate GUS
>tables.
>
>It seems that you could test (1) by starting up sqlplus as the user that
>ran the "ga" and typing "select <sequence-name>.nextval from dual".
>
>  
>
we did this and we noticed that any sequence.nextval returned 1. I think 
that's why we got the same message than Thomas, "DBD::Oracle::st execute 
failed: ORA-00001: unique constraint (CORE.PK_ALGORITHMIMPLEMENTATION) 
violated". We didn't get any permission issues.

To fix this we have reset the sequences to a high number to make sure 
they don't clash with already existing PK values. Well it's a temporary 
hack !

Arnaud

>On Thu, 2004-07-22 at 15:08, Arnaud Kerhornou wrote:
>  
>
>>Hi
>>
>>The same problem ocurred to me recently. When we checked the Oracle 
>>sequences, they were all set to 1 though there were some rows in some 
>>tables. I don't know why that has happened.
>>
>>Does anyone have an idea why the sequences could be reset to 1 ?
>>
>>Arnaud
>>
>>Thomas Otto wrote:
>>
>>    
>>
>>>Folks,
>>>
>>>I found my error:
>>>The problem was, that the sequences of the tables in the oracle didn't 
>>>display the realy primarykey number. I do not know why, but I will 
>>>have an eye on it.
>>>I modify the 'lastnumber', and know it seems to work out.
>>>
>>>Cheers,
>>>Thomas
>>>Thomas Otto wrote:
>>>
>>>      
>>>
>>>>Hi,
>>>>
>>>>I did an update via cvs, rebuild the stuff, worked more or less fine.
>>>>
>>>>But this the ga wanted to be registered another time:
>>>>USER ERROR: GUS::PluginMgr::GusApplication revision 1.52 has not been 
>>>>registered.
>>>>Please use 'ga +meta --commit'
>>>>
>>>>The error of this command see below. There is a conflict of the 
>>>>primary key...
>>>>So I changed the cvs version and the MD5 checksum in the table.
>>>>
>>>>But I have to do this for all the plugins - no fun...
>>>>
>>>>Who can help me?
>>>>
>>>>Thomas
>>>>
>>>>
>>>>ERROR: of ga + meta --commit
>>>>DBD::Oracle::st execute failed: ORA-00001: unique constraint 
>>>>(CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: 
>>>>OCIStmtExecute) at 
>>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
>>>>
>>>>SQL ERROR!! involving
>>>>
>>>>   INSERT INTO Core.AlgorithmImplementation (  other_read, 
>>>>group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
>>>>user_read, row_user_id, description, algorithm_implementation_id, 
>>>>other_write, modification_date, row_project_id, 
>>>>row_alg_invocation_id, executable_md5, executable, row_group_id, 
>>>>user_write )
>>>>   VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
>>>>?, ? ) Values: 1, 1, 1.52, 2, 1,  , 1, 1, update for GUS 3.0, 22, 0, 
>>>>1, 1, c1212c2753960e177d29b40d5a313f59, 
>>>>GUS::PluginMgr::GusApplication, 1, 1 at 
>>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
>>>>       
>>>>GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','\x{a} 
>>>>SQL ERROR!! involving\x{a} \x{a}    INSERT INTO 
>>>>Core.AlgorithmImple...') called at 
>>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 148
>>>>       
>>>>GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','GUS::ObjRelP::DbiDbHandle::st=HASH(0x87d1e30)','ARRAY(0x87d1ef0)','\x{a}    
>>>>INSERT INTO Core.AlgorithmImplementation (  other_read, ...') called 
>>>>at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681
>>>>       
>>>>GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','HASH(0x86f1b28)') 
>>>>called at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628
>>>>       
>>>>GUS::ObjRelP::DbiRow::insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)') 
>>>>called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677
>>>>       
>>>>GUS::Model::GusRow::submit('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','undef',1) 
>>>>called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1764
>>>>       
>>>>GUS::Model::GusRow::submitChildrenInClass('GUS::Model::Core::Algorithm=HASH(0x8690ff8)','GUS::Model::Core::AlgorithmImplementation') 
>>>>called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1745
>>>>       
>>>>GUS::Model::GusRow::submitAllChildren('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
>>>>called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684
>>>>       
>>>>GUS::Model::GusRow::submit('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
>>>>called at 
>>>>/home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 361
>>>>       
>>>>GUS::PluginMgr::GusApplication::doMajorMode_Meta('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
>>>>called at 
>>>>/home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 289
>>>>       
>>>>GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
>>>>called at 
>>>>/home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 198
>>>>       
>>>>GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','ARRAY(0x8060684)') 
>>>>called at /home/oracle/gus_home/bin/ga line 11
>>>>
>>>>
>>>>
>>>>ERROR of Submitrow:
>>>>DBD::Oracle::st execute failed: ORA-00001: unique constraint 
>>>>(CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: 
>>>>OCIStmtExecute) at 
>>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
>>>>
>>>>SQL ERROR!! involving
>>>>
>>>>   INSERT INTO Core.AlgorithmImplementation (  other_read, 
>>>>group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
>>>>user_read, row_user_id, description, algorithm_implementation_id, 
>>>>other_write, modification_date, row_project_id, 
>>>>row_alg_invocation_id, executable_md5, executable, row_group_id, 
>>>>user_write )
>>>>   VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
>>>>?, ? ) Values: 1, 1, 1.9, 3, 1,  , 1, 1, make consistent with GUS 
>>>>3.0, 24, 0, 1, 1, 60470c8cf30c7cea218fcbbb48840d97, 
>>>>GUS::Common::Plugin::SubmitRow, 1, 1 at 
>>>>/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>FREE Java Enterprise J2EE developer tools!
>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>>_______________________________________________
>>>>Gusdev-gusdev mailing list
>>>>Gus...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>
>>>>        
>>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>FREE Java Enterprise J2EE developer tools!
>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>_______________________________________________
>>>Gusdev-gusdev mailing list
>>>Gus...@li...
>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>
>>>      
>>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>FREE Java Enterprise J2EE developer tools!
>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>_______________________________________________
>>Gusdev-gusdev mailing list
>>Gus...@li...
>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>    
>>
>
>  
>

Maybe the cause was a twofold problem:

1. The select against the sequence.nextval failed because of database
permission problems, and
2. The application is coded to populate the new primary key with
maxval+1 in case of (1)

I have seen this series of events while using plugins to populate GUS
tables.

It seems that you could test (1) by starting up sqlplus as the user that
ran the "ga" and typing "select <sequence-name>.nextval from dual".

On Thu, 2004-07-22 at 15:08, Arnaud Kerhornou wrote:
> Hi
> 
> The same problem ocurred to me recently. When we checked the Oracle 
> sequences, they were all set to 1 though there were some rows in some 
> tables. I don't know why that has happened.
> 
> Does anyone have an idea why the sequences could be reset to 1 ?
> 
> Arnaud
> 
> Thomas Otto wrote:
> 
> > Folks,
> >
> > I found my error:
> > The problem was, that the sequences of the tables in the oracle didn't 
> > display the realy primarykey number. I do not know why, but I will 
> > have an eye on it.
> > I modify the 'lastnumber', and know it seems to work out.
> >
> > Cheers,
> > Thomas
> > Thomas Otto wrote:
> >
> >> Hi,
> >>
> >> I did an update via cvs, rebuild the stuff, worked more or less fine.
> >>
> >> But this the ga wanted to be registered another time:
> >> USER ERROR: GUS::PluginMgr::GusApplication revision 1.52 has not been 
> >> registered.
> >> Please use 'ga +meta --commit'
> >>
> >> The error of this command see below. There is a conflict of the 
> >> primary key...
> >> So I changed the cvs version and the MD5 checksum in the table.
> >>
> >> But I have to do this for all the plugins - no fun...
> >>
> >> Who can help me?
> >>
> >> Thomas
> >>
> >>
> >> ERROR: of ga + meta --commit
> >> DBD::Oracle::st execute failed: ORA-00001: unique constraint 
> >> (CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: 
> >> OCIStmtExecute) at 
> >> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
> >>
> >> SQL ERROR!! involving
> >>
> >>    INSERT INTO Core.AlgorithmImplementation (  other_read, 
> >> group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
> >> user_read, row_user_id, description, algorithm_implementation_id, 
> >> other_write, modification_date, row_project_id, 
> >> row_alg_invocation_id, executable_md5, executable, row_group_id, 
> >> user_write )
> >>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
> >> ?, ? ) Values: 1, 1, 1.52, 2, 1,  , 1, 1, update for GUS 3.0, 22, 0, 
> >> 1, 1, c1212c2753960e177d29b40d5a313f59, 
> >> GUS::PluginMgr::GusApplication, 1, 1 at 
> >> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
> >>        
> >> GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','\x{a} 
> >> SQL ERROR!! involving\x{a} \x{a}    INSERT INTO 
> >> Core.AlgorithmImple...') called at 
> >> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 148
> >>        
> >> GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','GUS::ObjRelP::DbiDbHandle::st=HASH(0x87d1e30)','ARRAY(0x87d1ef0)','\x{a}    
> >> INSERT INTO Core.AlgorithmImplementation (  other_read, ...') called 
> >> at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681
> >>        
> >> GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','HASH(0x86f1b28)') 
> >> called at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628
> >>        
> >> GUS::ObjRelP::DbiRow::insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)') 
> >> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677
> >>        
> >> GUS::Model::GusRow::submit('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','undef',1) 
> >> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1764
> >>        
> >> GUS::Model::GusRow::submitChildrenInClass('GUS::Model::Core::Algorithm=HASH(0x8690ff8)','GUS::Model::Core::AlgorithmImplementation') 
> >> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1745
> >>        
> >> GUS::Model::GusRow::submitAllChildren('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
> >> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684
> >>        
> >> GUS::Model::GusRow::submit('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
> >> called at 
> >> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 361
> >>        
> >> GUS::PluginMgr::GusApplication::doMajorMode_Meta('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
> >> called at 
> >> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 289
> >>        
> >> GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
> >> called at 
> >> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 198
> >>        
> >> GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','ARRAY(0x8060684)') 
> >> called at /home/oracle/gus_home/bin/ga line 11
> >>
> >>
> >>
> >> ERROR of Submitrow:
> >> DBD::Oracle::st execute failed: ORA-00001: unique constraint 
> >> (CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: 
> >> OCIStmtExecute) at 
> >> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
> >>
> >> SQL ERROR!! involving
> >>
> >>    INSERT INTO Core.AlgorithmImplementation (  other_read, 
> >> group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
> >> user_read, row_user_id, description, algorithm_implementation_id, 
> >> other_write, modification_date, row_project_id, 
> >> row_alg_invocation_id, executable_md5, executable, row_group_id, 
> >> user_write )
> >>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
> >> ?, ? ) Values: 1, 1, 1.9, 3, 1,  , 1, 1, make consistent with GUS 
> >> 3.0, 24, 0, 1, 1, 60470c8cf30c7cea218fcbbb48840d97, 
> >> GUS::Common::Plugin::SubmitRow, 1, 1 at 
> >> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by BEA Weblogic Workshop
> >> FREE Java Enterprise J2EE developer tools!
> >> Get your free copy of BEA WebLogic Workshop 8.1 today.
> >> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> >> _______________________________________________
> >> Gusdev-gusdev mailing list
> >> Gus...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > _______________________________________________
> > Gusdev-gusdev mailing list
> > Gus...@li...
> > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> >
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Hi

The same problem ocurred to me recently. When we checked the Oracle 
sequences, they were all set to 1 though there were some rows in some 
tables. I don't know why that has happened.

Does anyone have an idea why the sequences could be reset to 1 ?

Arnaud

Thomas Otto wrote:

> Folks,
>
> I found my error:
> The problem was, that the sequences of the tables in the oracle didn't 
> display the realy primarykey number. I do not know why, but I will 
> have an eye on it.
> I modify the 'lastnumber', and know it seems to work out.
>
> Cheers,
> Thomas
> Thomas Otto wrote:
>
>> Hi,
>>
>> I did an update via cvs, rebuild the stuff, worked more or less fine.
>>
>> But this the ga wanted to be registered another time:
>> USER ERROR: GUS::PluginMgr::GusApplication revision 1.52 has not been 
>> registered.
>> Please use 'ga +meta --commit'
>>
>> The error of this command see below. There is a conflict of the 
>> primary key...
>> So I changed the cvs version and the MD5 checksum in the table.
>>
>> But I have to do this for all the plugins - no fun...
>>
>> Who can help me?
>>
>> Thomas
>>
>>
>> ERROR: of ga + meta --commit
>> DBD::Oracle::st execute failed: ORA-00001: unique constraint 
>> (CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: 
>> OCIStmtExecute) at 
>> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
>>
>> SQL ERROR!! involving
>>
>>    INSERT INTO Core.AlgorithmImplementation (  other_read, 
>> group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
>> user_read, row_user_id, description, algorithm_implementation_id, 
>> other_write, modification_date, row_project_id, 
>> row_alg_invocation_id, executable_md5, executable, row_group_id, 
>> user_write )
>>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
>> ?, ? ) Values: 1, 1, 1.52, 2, 1,  , 1, 1, update for GUS 3.0, 22, 0, 
>> 1, 1, c1212c2753960e177d29b40d5a313f59, 
>> GUS::PluginMgr::GusApplication, 1, 1 at 
>> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
>>        
>> GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','\x{a} 
>> SQL ERROR!! involving\x{a} \x{a}    INSERT INTO 
>> Core.AlgorithmImple...') called at 
>> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 148
>>        
>> GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','GUS::ObjRelP::DbiDbHandle::st=HASH(0x87d1e30)','ARRAY(0x87d1ef0)','\x{a}    
>> INSERT INTO Core.AlgorithmImplementation (  other_read, ...') called 
>> at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681
>>        
>> GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','HASH(0x86f1b28)') 
>> called at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628
>>        
>> GUS::ObjRelP::DbiRow::insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)') 
>> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677
>>        
>> GUS::Model::GusRow::submit('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','undef',1) 
>> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1764
>>        
>> GUS::Model::GusRow::submitChildrenInClass('GUS::Model::Core::Algorithm=HASH(0x8690ff8)','GUS::Model::Core::AlgorithmImplementation') 
>> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1745
>>        
>> GUS::Model::GusRow::submitAllChildren('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
>> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684
>>        
>> GUS::Model::GusRow::submit('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
>> called at 
>> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 361
>>        
>> GUS::PluginMgr::GusApplication::doMajorMode_Meta('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
>> called at 
>> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 289
>>        
>> GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
>> called at 
>> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 198
>>        
>> GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','ARRAY(0x8060684)') 
>> called at /home/oracle/gus_home/bin/ga line 11
>>
>>
>>
>> ERROR of Submitrow:
>> DBD::Oracle::st execute failed: ORA-00001: unique constraint 
>> (CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: 
>> OCIStmtExecute) at 
>> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
>>
>> SQL ERROR!! involving
>>
>>    INSERT INTO Core.AlgorithmImplementation (  other_read, 
>> group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
>> user_read, row_user_id, description, algorithm_implementation_id, 
>> other_write, modification_date, row_project_id, 
>> row_alg_invocation_id, executable_md5, executable, row_group_id, 
>> user_write )
>>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
>> ?, ? ) Values: 1, 1, 1.9, 3, 1,  , 1, 1, make consistent with GUS 
>> 3.0, 24, 0, 1, 1, 60470c8cf30c7cea218fcbbb48840d97, 
>> GUS::Common::Plugin::SubmitRow, 1, 1 at 
>> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Folks,

I found my error:
The problem was, that the sequences of the tables in the oracle didn't 
display the realy primarykey number. I do not know why, but I will have 
an eye on it.
I modify the 'lastnumber', and know it seems to work out.

Cheers,
Thomas
Thomas Otto wrote:

> Hi,
>
> I did an update via cvs, rebuild the stuff, worked more or less fine.
>
> But this the ga wanted to be registered another time:
> USER ERROR: GUS::PluginMgr::GusApplication revision 1.52 has not been 
> registered.
> Please use 'ga +meta --commit'
>
> The error of this command see below. There is a conflict of the 
> primary key...
> So I changed the cvs version and the MD5 checksum in the table.
>
> But I have to do this for all the plugins - no fun...
>
> Who can help me?
>
> Thomas
>
>
> ERROR: of ga + meta --commit
> DBD::Oracle::st execute failed: ORA-00001: unique constraint 
> (CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: OCIStmtExecute) 
> at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
>
> SQL ERROR!! involving
>
>    INSERT INTO Core.AlgorithmImplementation (  other_read, 
> group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
> user_read, row_user_id, description, algorithm_implementation_id, 
> other_write, modification_date, row_project_id, row_alg_invocation_id, 
> executable_md5, executable, row_group_id, user_write )
>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
> ?, ? ) Values: 1, 1, 1.52, 2, 1,  , 1, 1, update for GUS 3.0, 22, 0, 
> 1, 1, c1212c2753960e177d29b40d5a313f59, 
> GUS::PluginMgr::GusApplication, 1, 1 at 
> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
>        
> GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','\x{a} 
> SQL ERROR!! involving\x{a} \x{a}    INSERT INTO 
> Core.AlgorithmImple...') called at 
> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 148
>        
> GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','GUS::ObjRelP::DbiDbHandle::st=HASH(0x87d1e30)','ARRAY(0x87d1ef0)','\x{a}    
> INSERT INTO Core.AlgorithmImplementation (  other_read, ...') called 
> at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681
>        
> GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','HASH(0x86f1b28)') 
> called at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628
>        
> GUS::ObjRelP::DbiRow::insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)') 
> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677
>        
> GUS::Model::GusRow::submit('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','undef',1) 
> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1764
>        
> GUS::Model::GusRow::submitChildrenInClass('GUS::Model::Core::Algorithm=HASH(0x8690ff8)','GUS::Model::Core::AlgorithmImplementation') 
> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1745
>        
> GUS::Model::GusRow::submitAllChildren('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
> called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684
>        
> GUS::Model::GusRow::submit('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
> called at 
> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 361
>        
> GUS::PluginMgr::GusApplication::doMajorMode_Meta('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
> called at 
> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 289
>        
> GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
> called at 
> /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 198
>        
> GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','ARRAY(0x8060684)') 
> called at /home/oracle/gus_home/bin/ga line 11
>
>
>
> ERROR of Submitrow:
> DBD::Oracle::st execute failed: ORA-00001: unique constraint 
> (CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: OCIStmtExecute) 
> at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.
>
> SQL ERROR!! involving
>
>    INSERT INTO Core.AlgorithmImplementation (  other_read, 
> group_write, cvs_revision, algorithm_id, group_read, cvs_tag, 
> user_read, row_user_id, description, algorithm_implementation_id, 
> other_write, modification_date, row_project_id, row_alg_invocation_id, 
> executable_md5, executable, row_group_id, user_write )
>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, 
> ?, ? ) Values: 1, 1, 1.9, 3, 1,  , 1, 1, make consistent with GUS 3.0, 
> 24, 0, 1, 1, 60470c8cf30c7cea218fcbbb48840d97, 
> GUS::Common::Plugin::SubmitRow, 1, 1 at 
> /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Hi,

It is possible that even if you have all the indexes, your statistics may 
need to be updated.

By the way, here is a list of our create indexes for Taxon:

create index SRES.TAXON_IND01 on sres.Taxon (NCBI_TAX_ID)  TABLESPACE 
INDX;
create index SRES.TAXON_IND02 on sres.Taxon (GENETIC_CODE_ID)  TABLESPACE 
INDX;
create index SRES.TAXON_IND03 on sres.Taxon 
(MITOCHONDRIAL_GENETIC_CODE_ID)  TABLESPACE INDX;
create index SRES.TAXON_IND04 on sres.Taxon (PARENT_ID)  TABLESPACE INDX;

You can run the plugin without --commit and with --sqlVerbose to see all 
the sql output the plugin is executing. You could also run it with --debug 
to turn debugging on.

                                                         Debbie

On Wed, 21 Jul 2004, Deborah F. Pinney wrote:

> Hi Juan,
>
> I ran the current version of LoadTaxon 2 weeks ago without this problem so I 
> wonder if there is something different about your schema. Specifically, you 
> may be missing an index that we have. Our Taxon table has the following 
> indexes: taxon_id, ncbi_tax_id,genetic_code_id,mitochondrial_genetic_code_id, 
> and parent_id. For example, the subroutine that inserts rows into TaxonName, 
> queries the Taxon table using ncbi_tax_id and without an index, each 
> taxonname record would require a full table scan of the taxon table.
>
> Could you check for this? Does anyone else have an idea?
>
>                                                       Debbie
>
>
> On Tue, 20 Jul 2004, Juan Perin wrote:
>
>> I assumed it was doing work, as you said, it appeared to be wrapping 
>> things
>> up, although I let it sit for over 24 hours in this state, and nothing
>> happened.  This is the only reason I killed it, and it seems to do that
>> every time I run the plugin.  Perhaps, something is wrong with our
>> configuration, although so far no other database upload has had errors. 
>> We
>> still have a few more to go though.
>> 
>> THANKS
>> 
>>> Hi,
>>> 
>>> You appear to have cancelled the plugin as it was entering data into
>>> dots.TaxonName which it does after filling dots.Taxon. It was actually
>>> doing work and not just hanging. The plugin should probably be modified 
>>> to
>>> have some intermittent output giving the status of the operation so that
>>> the operator is aware that it isn't just hanging. I will look into doing
>>> that.
>>> 
>>> The last update I did took about 1.25 hours but that will vary with your
>>> servers and how busy the database is. I don't have the numbers for the
>>> initial entry.
>>> 
>>>                                                     Debbie
>>> 
>>> 
>>> 
>>> On Tue, 20 Jul 2004, Juan Perin wrote:
>>> 
>>>> When initially populating the Taxonomy database, the population of the
>>>> tables with taxon_id's runs until what appears to be the last entry 
>>>> and
>>>> hangs indefinitely.  The following is the output after Ctrl-c 'ing to 
>>>> try to
>>>> escape.  After checking the tables, they seem to be populated fine, 
>>>> and the
>>>> number of entries seems consistent with the number of entries given in 
>>>> the
>>>> taxonomy database.
>>>> 
>>>> DBD::Oracle::db commit failed: ORA-01013: user requested cancel of 
>>>> current
>>>> operation (DBD ERROR: OCITransCommit) at
>>>> /checkout/GUS/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 479, <NODES> 
>>>> line
>>>> 225327.
>>>> DBD::Oracle::st execute failed: ORA-01013: user requested cancel of 
>>>> current
>>>> operation (DBD ERROR: OCIStmtExecute) [for Statement "select
>>>> SRes.TaxonName_SQ.NEXTVAL from DUAL"] at
>>>> /checkout/GUS/lib/perl/GUS/ObjRelP/DbiTable.pm line 555, <NODES> line
>>>> 225327.
>>>> 
>>>> Also... How long should this initial process take?  The first run took 
>>>> well
>>>> over 24 hours, but subsequent runs ran over about 20 minutes...
>>>> 
>>>> -Juan Perin
>>>> 
>>>> 
>>>> 
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>>> FREE Java Enterprise J2EE developer tools!
>>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>> _______________________________________________
>>>> Gusdev-gusdev mailing list
>>>> Gus...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>> 
>>> 
>>> 
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>> FREE Java Enterprise J2EE developer tools!
>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>> 
>> 
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

On Tue, 20 Jul 2004, Sucheta Tripathy wrote:

> Hi,
>
> The Keyword features were commented in the earlier versions of GBParser. I 
> did not see any change in that area in the newer versions. Has anyone already 
> worked on it?

I don't think anyone here has done anything with keywords.

>
> Also has anyone got the repeat features populated using GBParser. In my case 
> the repeat features get partially populated. For example I don't get relevant 
> information in repeats.map, repeats.repeat_type, repeats.repeat_unit etc. The 
> repeat view does not have place for storing the repeat regions like beginning 
> at say 6790 and ending at 6800 and also the repeat sequences are not stored.

repeats.map, repeats.rpt_type, and repeat.rpt_unit are filled with the 
GBParser plugin in our hands. Are you testing with records that have the 
data used?

The location information is stored in dots.nalocation which has a foreign 
key to repeats (na_feature_id).

                                                            Debbie

>
> Any thoughts ??
>
>
> Sucheta
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Hi Juan,

I ran the current version of LoadTaxon 2 weeks ago without this problem so 
I wonder if there is something different about your schema. Specifically, 
you may be missing an index that we have. Our Taxon table has the 
following indexes: taxon_id, 
ncbi_tax_id,genetic_code_id,mitochondrial_genetic_code_id, and parent_id. 
For example, the subroutine that inserts rows into TaxonName, queries the 
Taxon table using ncbi_tax_id and without an index, each taxonname record 
would require a full table scan of the taxon table.

Could you check for this? Does anyone else have an idea?

                                                        Debbie

On Tue, 20 Jul 2004, Juan Perin wrote:

> I assumed it was doing work, as you said, it appeared to be wrapping things
> up, although I let it sit for over 24 hours in this state, and nothing
> happened.  This is the only reason I killed it, and it seems to do that
> every time I run the plugin.  Perhaps, something is wrong with our
> configuration, although so far no other database upload has had errors.  We
> still have a few more to go though.
>
> THANKS
>
>> Hi,
>>
>> You appear to have cancelled the plugin as it was entering data into
>> dots.TaxonName which it does after filling dots.Taxon. It was actually
>> doing work and not just hanging. The plugin should probably be modified to
>> have some intermittent output giving the status of the operation so that
>> the operator is aware that it isn't just hanging. I will look into doing
>> that.
>>
>> The last update I did took about 1.25 hours but that will vary with your
>> servers and how busy the database is. I don't have the numbers for the
>> initial entry.
>>
>>                                                     Debbie
>>
>>
>>
>> On Tue, 20 Jul 2004, Juan Perin wrote:
>>
>>> When initially populating the Taxonomy database, the population of the
>>> tables with taxon_id's runs until what appears to be the last entry and
>>> hangs indefinitely.  The following is the output after Ctrl-c 'ing to try to
>>> escape.  After checking the tables, they seem to be populated fine, and the
>>> number of entries seems consistent with the number of entries given in the
>>> taxonomy database.
>>>
>>> DBD::Oracle::db commit failed: ORA-01013: user requested cancel of current
>>> operation (DBD ERROR: OCITransCommit) at
>>> /checkout/GUS/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 479, <NODES> line
>>> 225327.
>>> DBD::Oracle::st execute failed: ORA-01013: user requested cancel of current
>>> operation (DBD ERROR: OCIStmtExecute) [for Statement "select
>>> SRes.TaxonName_SQ.NEXTVAL from DUAL"] at
>>> /checkout/GUS/lib/perl/GUS/ObjRelP/DbiTable.pm line 555, <NODES> line
>>> 225327.
>>>
>>> Also... How long should this initial process take?  The first run took well
>>> over 24 hours, but subsequent runs ran over about 20 minutes...
>>>
>>> -Juan Perin
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>> FREE Java Enterprise J2EE developer tools!
>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>

Hi,

The Keyword features were commented in the earlier versions of GBParser. I 
did not see any change in that area in the newer versions. Has anyone 
already worked on it?

Also has anyone got the repeat features populated using GBParser. In my 
case the repeat features get partially populated. For example I don't get 
relevant information in repeats.map, repeats.repeat_type, 
repeats.repeat_unit etc. The repeat view does not have place for storing 
the repeat regions like beginning at say 6790 and ending at 6800 and also 
the repeat sequences are not stored.

Any thoughts ??

Sucheta

Hi,

You appear to have cancelled the plugin as it was entering data into 
dots.TaxonName which it does after filling dots.Taxon. It was actually 
doing work and not just hanging. The plugin should probably be modified to 
have some intermittent output giving the status of the operation so that 
the operator is aware that it isn't just hanging. I will look into doing 
that.

The last update I did took about 1.25 hours but that will vary with your 
servers and how busy the database is. I don't have the numbers for the 
initial entry.

                                                      Debbie

On Tue, 20 Jul 2004, Juan Perin wrote:

> When initially populating the Taxonomy database, the population of the
> tables with taxon_id's runs until what appears to be the last entry and
> hangs indefinitely.  The following is the output after Ctrl-c 'ing to try to
> escape.  After checking the tables, they seem to be populated fine, and the
> number of entries seems consistent with the number of entries given in the
> taxonomy database.
>
> DBD::Oracle::db commit failed: ORA-01013: user requested cancel of current
> operation (DBD ERROR: OCITransCommit) at
> /checkout/GUS/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 479, <NODES> line
> 225327.
> DBD::Oracle::st execute failed: ORA-01013: user requested cancel of current
> operation (DBD ERROR: OCIStmtExecute) [for Statement "select
> SRes.TaxonName_SQ.NEXTVAL from DUAL"] at
> /checkout/GUS/lib/perl/GUS/ObjRelP/DbiTable.pm line 555, <NODES> line
> 225327.
>
> Also... How long should this initial process take?  The first run took well
> over 24 hours, but subsequent runs ran over about 20 minutes...
>
> -Juan Perin
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

When initially populating the Taxonomy database, the population of the
tables with taxon_id's runs until what appears to be the last entry and
hangs indefinitely.  The following is the output after Ctrl-c 'ing to try to
escape.  After checking the tables, they seem to be populated fine, and the
number of entries seems consistent with the number of entries given in the
taxonomy database. 

DBD::Oracle::db commit failed: ORA-01013: user requested cancel of current
operation (DBD ERROR: OCITransCommit) at
/checkout/GUS/lib/perl/GUS/ObjRelP/DbiDatabase.pm line 479, <NODES> line
225327.
DBD::Oracle::st execute failed: ORA-01013: user requested cancel of current
operation (DBD ERROR: OCIStmtExecute) [for Statement "select
SRes.TaxonName_SQ.NEXTVAL from DUAL"] at
/checkout/GUS/lib/perl/GUS/ObjRelP/DbiTable.pm line 555, <NODES> line
225327.

Also... How long should this initial process take?  The first run took well
over 24 hours, but subsequent runs ran over about 20 minutes...

-Juan Perin

Perhaps all that is needed is the table DoTS::SimilarityKeyword.

Jonathan Schug <js...@pc...> writes:
>
> Sucheta, and All:
>
> If the blast libraries do not overlap, i.e., contain different sets of
> sequences, then there is probably no problem.  You can simply
> distinguish the Similarity rows by the target sequence's
> external_database_release_id.
>
> If the libraries overlap, then the issue is more difficult.  We don't
> have the notion of a library in this sense, and of course the library
> size affects the p-values for matches.  There is a DoTS::Library table
> that holds clone information that could be hacked to provide what you
> want, but I do *not* recommend it as a long term solution.  You could
> also use the DoTS::DbRefNaSequence or DoTS::AASequenceDbRef as
> appropriate to link to a DoTS::DbRef which links to an
> ExternalDatabase.  These tables could easily be used to gather
> sequences into multiple BLAST database files.
>
> The best solution is probably to create new tables.
>
> I propose, then the following changes to the Similarity table and the
> addition of new table to track search libraries:
>
> DoTS::Similarity
>    - add search_algorithm_invocation_id link to stably point to
> parameter values for the search.
>
> SRes::SearchLibrary
>    - contains a description of the search library including entry count
> etc.
>
> SRes::SearchLibraryMember
>    - uses a soft link, i.e., table_id, row_id to indicate membership.
>    - link is soft so that SearchLibrary can also be used for motifs,
> etc. that may not be in sequence table.
>    - SearchLibrary might contain a table_id to record what kind of
> entries are in the library.
>
> Thoughts?
>
> Jonathan
>

Hi,

I did an update via cvs, rebuild the stuff, worked more or less fine.

But this the ga wanted to be registered another time:
USER ERROR: GUS::PluginMgr::GusApplication revision 1.52 has not been 
registered.
Please use 'ga +meta --commit'

The error of this command see below. There is a conflict of the primary 
key...
So I changed the cvs version and the MD5 checksum in the table.

But I have to do this for all the plugins - no fun...

Who can help me?

Thomas

ERROR: of ga + meta --commit
DBD::Oracle::st execute failed: ORA-00001: unique constraint 
(CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: OCIStmtExecute) 
at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.

 SQL ERROR!! involving

    INSERT INTO Core.AlgorithmImplementation (  other_read, group_write, 
cvs_revision, algorithm_id, group_read, cvs_tag, user_read, row_user_id, 
description, algorithm_implementation_id, other_write, 
modification_date, row_project_id, row_alg_invocation_id, 
executable_md5, executable, row_group_id, user_write )
    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, ?, 
? ) 
 Values: 1, 1, 1.52, 2, 1,  , 1, 1, update for GUS 3.0, 22, 0, 1, 1, 
c1212c2753960e177d29b40d5a313f59, GUS::PluginMgr::GusApplication, 1, 1 
at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185

GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','\x{a} 
SQL ERROR!! involving\x{a} \x{a}    INSERT INTO Core.AlgorithmImple...') 
called at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 148

GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8691088)','GUS::ObjRelP::DbiDbHandle::st=HASH(0x87d1e30)','ARRAY(0x87d1ef0)','\x{a}    
INSERT INTO Core.AlgorithmImplementation (  other_read, ...') called at 
/home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681

GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','HASH(0x86f1b28)') 
called at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628

GUS::ObjRelP::DbiRow::insert('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)') 
called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677

GUS::Model::GusRow::submit('GUS::Model::Core::AlgorithmImplementation=HASH(0x870d390)','undef',1) 
called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1764

GUS::Model::GusRow::submitChildrenInClass('GUS::Model::Core::Algorithm=HASH(0x8690ff8)','GUS::Model::Core::AlgorithmImplementation') 
called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1745

GUS::Model::GusRow::submitAllChildren('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
called at /home/oracle/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684

GUS::Model::GusRow::submit('GUS::Model::Core::Algorithm=HASH(0x8690ff8)') 
called at /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm 
line 361

GUS::PluginMgr::GusApplication::doMajorMode_Meta('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
called at /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm 
line 289

GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','undef') 
called at /home/oracle/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm 
line 198

GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x804d00c)','ARRAY(0x8060684)') 
called at /home/oracle/gus_home/bin/ga line 11

ERROR of Submitrow:
DBD::Oracle::st execute failed: ORA-00001: unique constraint 
(CORE.PK_ALGORITHMIMPLEMENTATION) violated (DBD ERROR: OCIStmtExecute) 
at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 145.

 SQL ERROR!! involving

    INSERT INTO Core.AlgorithmImplementation (  other_read, group_write, 
cvs_revision, algorithm_id, group_read, cvs_tag, user_read, row_user_id, 
description, algorithm_implementation_id, other_write, 
modification_date, row_project_id, row_alg_invocation_id, 
executable_md5, executable, row_group_id, user_write )
    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, ?, 
? ) 
 Values: 1, 1, 1.9, 3, 1,  , 1, 1, make consistent with GUS 3.0, 24, 0, 
1, 1, 60470c8cf30c7cea218fcbbb48840d97, GUS::Common::Plugin::SubmitRow, 
1, 1 at /home/oracle/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 185

Jinal:

Sorry, I didn't realize how poorly documented that plugin is.  Please  
cvs update for a better version.  The help should answer your  
questions.  To run the plugin, make sure you also have  
GUS/PluginMgr/lib/perl/PluginUtilities.pm and  
PluginUtilities/ConstraintFunctions.pm

Jonathan

On Jul 19, 2004, at 12:46 PM, Jinal Jhaveri wrote:

> Hi Jonathan,
> I tried to use the LoadEnzymeDatabase plugin and didn't understand  
> which
> enzyme file, prosite db file, swissprot file and omim file is it  
> trying to
> use? Is this plugin documented anywhere? Any files / links to the  
> files which
> I can grab from the web?
>
> thank you
> Jinal,
> On Wednesday 14 July 2004 12:20 am, you wrote:
>> Jinal:
>>
>> Sorry for the delay.  The plugin is
>> GUS::Common::Plugin::LoadEnzymeDatabase.  We'll try to provide any
>> necessary documentation, but it it meant to work with the flat file
>> that you can pick up on the web.
>>
>> Jonathan
>>
>>
>> ---------------------------------------------------------------------- 
>> --
>> ---
>> Jonathan Schug            Center for Bioinformatics
>> js...@pc...     Computational Biology and Informatics Lab
>> (215) 573-3113 voice      University of Pennsylvania,
>> (215) 573-3111 fax        1413 Blockley Hall, Philadelphia, PA
>> 19014-6021

Hi Jonathan,
I tried to use the LoadEnzymeDatabase plugin and didn't understand which 
enzyme file, prosite db file, swissprot file and omim file is it trying to 
use? Is this plugin documented anywhere? Any files / links to the files which 
I can grab from the web?

thank you
Jinal,
On Wednesday 14 July 2004 12:20 am, you wrote:
> Jinal:
>
> Sorry for the delay.  The plugin is
> GUS::Common::Plugin::LoadEnzymeDatabase.  We'll try to provide any
> necessary documentation, but it it meant to work with the flat file
> that you can pick up on the web.
>
> Jonathan
>
>
> ------------------------------------------------------------------------
> ---
> Jonathan Schug            Center for Bioinformatics
> js...@pc...     Computational Biology and Informatics Lab
> (215) 573-3113 voice      University of Pennsylvania,
> (215) 573-3111 fax        1413 Blockley Hall, Philadelphia, PA
> 19014-6021

Jinal:

I've updated plugin and committed.  Converted Disp to better  
CBIL::Util::Disp and fixed a few variable typos.

Jonathan

On Jul 19, 2004, at 12:34 PM, Jinal Jhaveri wrote:

> Ok I guess it was trying to look for Disp.pm in some other path. I  
> solved that
> but now i am getting the following error.
>
> gus@smaug:~$ ga +create GUS::Common::Plugin::LoadEnzymeDatabase
> Bareword found where operator expected
> at /home/gus/gushome/lib/perl/GUS/Common/Plugin/LoadEnzymeDatabase.pm  
> line
> 358, near "$ez _att_h"
>         (Missing operator before _att_h?)
>
> ERROR: syntax error
> at /home/gus/gushome/lib/perl/GUS/Common/Plugin/LoadEnzymeDatabase.pm  
> line
> 358, near "$ez _att_h "
> syntax error
> at /home/gus/gushome/lib/perl/GUS/Common/Plugin/LoadEnzymeDatabase.pm  
> line
> 364, near "}"
> Compilation failed in require at (eval 3) line 1.
>
>
> --------------------------- STACK TRACE -------------------------
>          
> GUS::PluginMgr::Plugin::error('GUS::PluginMgr:: 
> GusApplication=HASH(0x813e9a8)','syntax
> error at /home/gus/gushome/lib/perl/GUS/Common/Plugin/...') called
> at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 248
>          
> GUS::PluginMgr::GusApplication::newFromPluginName('GUS::PluginMgr:: 
> GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin:: 
> LoadEnzymeDatabase')
> called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm  
> line 664
>          
> GUS::PluginMgr::GusApplication::create_or_update_implementation('GUS:: 
> PluginMgr::GusApplication=HASH(0x813e9a8)',0,'GUS::Common::Plugin:: 
> LoadEnzymeDatabase')
> called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm  
> line 456
>          
> GUS::PluginMgr::GusApplication::doMajorMode_Create('GUS::PluginMgr:: 
> GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin:: 
> LoadEnzymeDatabase')
> called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm  
> line 283
>          
> GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr:: 
> GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin:: 
> LoadEnzymeDatabase')
> called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm  
> line 192
>          
> GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr:: 
> GusApplication=HASH(0x813e9a8)','ARRAY(0x814a7d0)')
> called at /home/gus/gushome/bin/ga line 11

Ok I guess it was trying to look for Disp.pm in some other path. I solved that 
but now i am getting the following error.

gus@smaug:~$ ga +create GUS::Common::Plugin::LoadEnzymeDatabase
Bareword found where operator expected 
at /home/gus/gushome/lib/perl/GUS/Common/Plugin/LoadEnzymeDatabase.pm line 
358, near "$ez _att_h"
        (Missing operator before _att_h?)

ERROR: syntax error 
at /home/gus/gushome/lib/perl/GUS/Common/Plugin/LoadEnzymeDatabase.pm line 
358, near "$ez _att_h "
syntax error 
at /home/gus/gushome/lib/perl/GUS/Common/Plugin/LoadEnzymeDatabase.pm line 
364, near "}"
Compilation failed in require at (eval 3) line 1.

--------------------------- STACK TRACE -------------------------
        GUS::PluginMgr::Plugin::error('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','syntax 
error at /home/gus/gushome/lib/perl/GUS/Common/Plugin/...') called 
at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 248
        GUS::PluginMgr::GusApplication::newFromPluginName('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin::LoadEnzymeDatabase') 
called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 664
        GUS::PluginMgr::GusApplication::create_or_update_implementation('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)',0,'GUS::Common::Plugin::LoadEnzymeDatabase') 
called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 456
        GUS::PluginMgr::GusApplication::doMajorMode_Create('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin::LoadEnzymeDatabase') 
called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 283
        GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin::LoadEnzymeDatabase') 
called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 192
        GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','ARRAY(0x814a7d0)') 
called at /home/gus/gushome/bin/ga line 11

I'd like to propose the following for a CpG island view on 
NAFeatureImp.  Comments?

Jonathan Schug

SELECT    na_feature_id,
           na_sequence_id,

	      /* 'CpgIslandNAFeature' */
           subclass_view,

           /* should be internal ID of SO:0000307 */
           sequence_ontology_id,
           name,
           parent_id,
           source_id,
           external_database_release_id,
           prediction_algorithm_id,
           is_predicted,
           review_status_id,

/* number of c or g bases */
int1   as cg_count,

/* redundant: fraction of length that is c or g base */
float1 as cg_fraction,

/* number of cg dinucleotides */
int2   as cpg_count,

/* redundant: fraction of (length - 1) dinucleotides that are cg */
float2 as cpg_fraction,

/* ratio of observed cg dinucs to expected cg dinucs */
float3 as cpg_observed_to_expected_ratio,

/* prediction invocation to get params that is safe from updates. */
int3   as algorithm_invocation_id

/* GUS overhead */
           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,

FROM NAFeatureImp WHERE subclass_view = 'CpgIslandNAFeature' WITH CHECK 
OPTION

Hi Jonathan

I am getting following errors while registering this plugin

ERROR: Can't locate Disp.pm in @INC (@INC 
contains: /home/gus/gushome/lib/perl /usr/lib/perl5/5.8.3/i486-linux /usr/lib/perl5/5.8.3 /usr/lib/perl5/site_perl/5.8.3/i486-linux /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl .) 
at /home/gus/gushome/lib/perl/GUS/Common/Plugin/LoadEnzymeDatabase.pm line 
10.
BEGIN failed--compilation aborted 
at /home/gus/gushome/lib/perl/GUS/Common/Plugin/LoadEnzymeDatabase.pm line 
10.
Compilation failed in require at (eval 3) line 1.

--------------------------- STACK TRACE -------------------------
        GUS::PluginMgr::Plugin::error('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','Can\'t 
locate Disp.pm in @INC (@INC contains: /home/gus/gusho...') called 
at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 248
        GUS::PluginMgr::GusApplication::newFromPluginName('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin::LoadEnzymeDatabase') 
called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 664
        GUS::PluginMgr::GusApplication::create_or_update_implementation('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)',0,'GUS::Common::Plugin::LoadEnzymeDatabase') 
called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 456
        GUS::PluginMgr::GusApplication::doMajorMode_Create('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin::LoadEnzymeDatabase') 
called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 283
        GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','GUS::Common::Plugin::LoadEnzymeDatabase') 
called at /home/gus/gushome/lib/perl/GUS/PluginMgr/GusApplication.pm line 192
        GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x813e9a8)','ARRAY(0x814a7d0)') 
called at /home/gus/gushome/bin/ga line 11

Any idea what am I missing?

thank you very much for your help!
--Jinal

On Monday 19 July 2004 12:13 pm, Jonathan Schug wrote:
> Jinal:
>
> I have just added GUS::Common::Plugin::LoadEnzymeDatabase
> (GUS/Common/plugin/perl/LoadEnzymeDatabase.pm) to the Sanger CVS.  It
> looks like it has been successfully run here.
>
> Jonathan
>
> On Jul 19, 2004, at 11:52 AM, Jinal Jhaveri wrote:
> > Hi Jonathan,
> > I tried to find the LoadEnzymeDatabase plugin but its not on the cvs
> > nor in my
> > installation. Can you please send it to me?
> >
> > thanks
> > --Jinal
> >
> > On Wednesday 14 July 2004 12:20 am, you wrote:
> >> Jinal:
> >>
> >> Sorry for the delay.  The plugin is
> >> GUS::Common::Plugin::LoadEnzymeDatabase.  We'll try to provide any
> >> necessary documentation, but it it meant to work with the flat file
> >> that you can pick up on the web.
> >>
> >> Jonathan
> >>
> >>
> >> ----------------------------------------------------------------------
> >> --
> >> ---
> >> Jonathan Schug            Center for Bioinformatics
> >> js...@pc...     Computational Biology and Informatics Lab
> >> (215) 573-3113 voice      University of Pennsylvania,
> >> (215) 573-3111 fax        1413 Blockley Hall, Philadelphia, PA
> >> 19014-6021
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Jinal:

I have just added GUS::Common::Plugin::LoadEnzymeDatabase  
(GUS/Common/plugin/perl/LoadEnzymeDatabase.pm) to the Sanger CVS.  It  
looks like it has been successfully run here.

Jonathan

On Jul 19, 2004, at 11:52 AM, Jinal Jhaveri wrote:

> Hi Jonathan,
> I tried to find the LoadEnzymeDatabase plugin but its not on the cvs  
> nor in my
> installation. Can you please send it to me?
>
> thanks
> --Jinal
> On Wednesday 14 July 2004 12:20 am, you wrote:
>> Jinal:
>>
>> Sorry for the delay.  The plugin is
>> GUS::Common::Plugin::LoadEnzymeDatabase.  We'll try to provide any
>> necessary documentation, but it it meant to work with the flat file
>> that you can pick up on the web.
>>
>> Jonathan
>>
>>
>> ---------------------------------------------------------------------- 
>> --
>> ---
>> Jonathan Schug            Center for Bioinformatics
>> js...@pc...     Computational Biology and Informatics Lab
>> (215) 573-3113 voice      University of Pennsylvania,
>> (215) 573-3111 fax        1413 Blockley Hall, Philadelphia, PA
>> 19014-6021

Got it.

Thanks

Sucheta
At 11:50 AM 7/19/2004 -0400, Jonathan Schug wrote:
>Sucheta:
>
>That info is in the NA (or AA) Sequence table.  Remember that the query
>and subject sequences can be in different external_database_releases so
>that info must be on the individual sequences, not the similarity.
>
>Jonathan
>
>On Jul 19, 2004, at 11:26 AM, Sucheta Tripathy wrote:
>
>>Hi Jonathan,
>>
>>Our databases are not really having any sequence overlap. So as you
>>suggested the external_database_release_id should be fine. But when I
>>look into the Dots.similarity and the dots.similarityspan I don't see
>>anything pointing to externaldatabase/externaldatabaserelease. I was
>>wondering if I missed out something or there is a linker.
>>
>>Thanks
>>
>>Sucheta
>>
>>At 10:00 AM 7/19/2004 -0400, Jonathan Schug wrote:
>>>Sucheta, and All:
>>>
>>>If the blast libraries do not overlap, i.e., contain different sets of
>>>sequences, then there is probably no problem.  You can simply
>>>distinguish the Similarity rows by the target sequence's
>>>external_database_release_id.
>>>
>>>If the libraries overlap, then the issue is more difficult.  We don't
>>>have the notion of a library in this sense, and of course the library
>>>size affects the p-values for matches.  There is a DoTS::Library table
>>>that holds clone information that could be hacked to provide what you
>>>want, but I do *not* recommend it as a long term solution.  You could
>>>also use the DoTS::DbRefNaSequence or DoTS::AASequenceDbRef as
>>>appropriate to link to a DoTS::DbRef which links to an
>>>ExternalDatabase.  These tables could easily be used to gather
>>>sequences into multiple BLAST database files.
>>>
>>>The best solution is probably to create new tables.
>>>
>>>I propose, then the following changes to the Similarity table and the
>>>addition of new table to track search libraries:
>>>
>>>DoTS::Similarity
>>>   - add search_algorithm_invocation_id link to stably point to
>>>parameter values for the search.
>>>
>>>SRes::SearchLibrary
>>>   - contains a description of the search library including entry count
>>>etc.
>>>
>>>SRes::SearchLibraryMember
>>>   - uses a soft link, i.e., table_id, row_id to indicate membership.
>>>   - link is soft so that SearchLibrary can also be used for motifs,
>>>etc. that may not be in sequence table.
>>>   - SearchLibrary might contain a table_id to record what kind of
>>>entries are in the library.
>>>
>>>Thoughts?
>>>
>>>Jonathan
>>>
>>>On Jul 19, 2004, at 9:31 AM, Sucheta Tripathy wrote:
>>>
>>>>Hi Jonathan,
>>>>
>>>>Thanks for your reply. I also have a similar concern which I posted
>>>>sometimes back. My concern is to do with multiple databases rather
>>>>than the parameters for blast search. Currently we want to store
>>>>blast
>>>>results against 23 different databases. Any suggestions which table
>>>>may be suitable?
>>>>
>>>>Thanks
>>>>
>>>>Sucheta
>>>>
>>>>At 12:18 AM 7/19/2004 -0400, Jonathan Schug wrote:
>>>>>Josef:
>>>>>
>>>>>The two columns in DoTS::Similarity that might be useful are
>>>>>algorithm
>>>>>and row_alg_invocation_id.  Algorithm is not recommended; it is
>>>>>meant
>>>>>to be used to distinguish, say, BLAST hits from FASTA hits.
>>>>>Row_alg_invocation_id is better and will work.  You can use the
>>>>>AlgoithmInvocation parameters.  However, this will not work if the
>>>>>rows
>>>>>are modified in some way later one.  Later updates will change the
>>>>>row_alg_invocation_id ruining this scheme.  You could also consider
>>>>>linking Similarity rows to the invocation via an Evidence row.  This
>>>>>is
>>>>>more stable.
>>>>>
>>>>>PlasmoDB faced this when tuning BLAST parameters to avoid the
>>>>>problems
>>>>>with the high AT content of the Pf genome.  They may have tuned the
>>>>>parameters outside of the DB.
>>>>>
>>>>>You might also consider running the BLAST searches with the most
>>>>>lenient parameters, then recreating the more stringent searches with
>>>>>query parameters if this is possible
>>>>>
>>>>>Jonathan
>>>>>
>>>>>
>>>>>-------------------------------------------------------------------- 
>>>>>-- -- ---
>>>>>Jonathan Schug            Center for Bioinformatics
>>>>>js...@pc...     Computational Biology and Informatics Lab
>>>>>(215) 573-3113 voice      University of Pennsylvania,
>>>>>(215) 573-3111 fax        1413 Blockley Hall, Philadelphia, PA
>>>>>19014-6021
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>FREE Java Enterprise J2EE developer tools!
>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>>>_______________________________________________
>>>>>Gusdev-gusdev mailing list
>>>>>Gus...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>FREE Java Enterprise J2EE developer tools!
>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>_______________________________________________
>>>Gusdev-gusdev mailing list
>>>Gus...@li...
>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Sucheta:

That info is in the NA (or AA) Sequence table.  Remember that the query  
and subject sequences can be in different external_database_releases so  
that info must be on the individual sequences, not the similarity.

Jonathan

On Jul 19, 2004, at 11:26 AM, Sucheta Tripathy wrote:

> Hi Jonathan,
>
> Our databases are not really having any sequence overlap. So as you  
> suggested the external_database_release_id should be fine. But when I  
> look into the Dots.similarity and the dots.similarityspan I don't see  
> anything pointing to externaldatabase/externaldatabaserelease. I was  
> wondering if I missed out something or there is a linker.
>
> Thanks
>
> Sucheta
>
> At 10:00 AM 7/19/2004 -0400, Jonathan Schug wrote:
>> Sucheta, and All:
>>
>> If the blast libraries do not overlap, i.e., contain different sets of
>> sequences, then there is probably no problem.  You can simply
>> distinguish the Similarity rows by the target sequence's
>> external_database_release_id.
>>
>> If the libraries overlap, then the issue is more difficult.  We don't
>> have the notion of a library in this sense, and of course the library
>> size affects the p-values for matches.  There is a DoTS::Library table
>> that holds clone information that could be hacked to provide what you
>> want, but I do *not* recommend it as a long term solution.  You could
>> also use the DoTS::DbRefNaSequence or DoTS::AASequenceDbRef as
>> appropriate to link to a DoTS::DbRef which links to an
>> ExternalDatabase.  These tables could easily be used to gather
>> sequences into multiple BLAST database files.
>>
>> The best solution is probably to create new tables.
>>
>> I propose, then the following changes to the Similarity table and the
>> addition of new table to track search libraries:
>>
>> DoTS::Similarity
>>   - add search_algorithm_invocation_id link to stably point to
>> parameter values for the search.
>>
>> SRes::SearchLibrary
>>   - contains a description of the search library including entry count
>> etc.
>>
>> SRes::SearchLibraryMember
>>   - uses a soft link, i.e., table_id, row_id to indicate membership.
>>   - link is soft so that SearchLibrary can also be used for motifs,
>> etc. that may not be in sequence table.
>>   - SearchLibrary might contain a table_id to record what kind of
>> entries are in the library.
>>
>> Thoughts?
>>
>> Jonathan
>>
>> On Jul 19, 2004, at 9:31 AM, Sucheta Tripathy wrote:
>>
>>> Hi Jonathan,
>>>
>>> Thanks for your reply. I also have a similar concern which I posted
>>> sometimes back. My concern is to do with multiple databases rather
>>> than the parameters for blast search. Currently we want to store  
>>> blast
>>> results against 23 different databases. Any suggestions which table
>>> may be suitable?
>>>
>>> Thanks
>>>
>>> Sucheta
>>>
>>> At 12:18 AM 7/19/2004 -0400, Jonathan Schug wrote:
>>>> Josef:
>>>>
>>>> The two columns in DoTS::Similarity that might be useful are  
>>>> algorithm
>>>> and row_alg_invocation_id.  Algorithm is not recommended; it is  
>>>> meant
>>>> to be used to distinguish, say, BLAST hits from FASTA hits.
>>>> Row_alg_invocation_id is better and will work.  You can use the
>>>> AlgoithmInvocation parameters.  However, this will not work if the
>>>> rows
>>>> are modified in some way later one.  Later updates will change the
>>>> row_alg_invocation_id ruining this scheme.  You could also consider
>>>> linking Similarity rows to the invocation via an Evidence row.  This
>>>> is
>>>> more stable.
>>>>
>>>> PlasmoDB faced this when tuning BLAST parameters to avoid the  
>>>> problems
>>>> with the high AT content of the Pf genome.  They may have tuned the
>>>> parameters outside of the DB.
>>>>
>>>> You might also consider running the BLAST searches with the most
>>>> lenient parameters, then recreating the more stringent searches with
>>>> query parameters if this is possible
>>>>
>>>> Jonathan
>>>>
>>>>
>>>> -------------------------------------------------------------------- 
>>>> -- -- ---
>>>> Jonathan Schug            Center for Bioinformatics
>>>> js...@pc...     Computational Biology and Informatics Lab
>>>> (215) 573-3113 voice      University of Pennsylvania,
>>>> (215) 573-3111 fax        1413 Blockley Hall, Philadelphia, PA
>>>> 19014-6021
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>>> FREE Java Enterprise J2EE developer tools!
>>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>> _______________________________________________
>>>> Gusdev-gusdev mailing list
>>>> Gus...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

2002	Jan	Feb	Mar	Apr	May	Jun (11)	Jul (34)	Aug (14)	Sep (10)	Oct (10)	Nov (11)	Dec (6)
2003	Jan (56)	Feb (76)	Mar (68)	Apr (11)	May (97)	Jun (16)	Jul (29)	Aug (35)	Sep (18)	Oct (32)	Nov (23)	Dec (77)
2004	Jan (52)	Feb (44)	Mar (55)	Apr (38)	May (106)	Jun (82)	Jul (76)	Aug (47)	Sep (36)	Oct (56)	Nov (46)	Dec (61)
2005	Jan (52)	Feb (118)	Mar (41)	Apr (40)	May (35)	Jun (99)	Jul (84)	Aug (104)	Sep (53)	Oct (107)	Nov (68)	Dec (30)
2006	Jan (19)	Feb (27)	Mar (24)	Apr (9)	May (22)	Jun (11)	Jul (34)	Aug (8)	Sep (15)	Oct (55)	Nov (16)	Dec (2)
2007	Jan (12)	Feb (4)	Mar (8)	Apr	May (19)	Jun (3)	Jul (1)	Aug (6)	Sep (12)	Oct (3)	Nov	Dec
2008	Jan (4)	Feb	Mar	Apr	May (1)	Jun (1)	Jul	Aug	Sep	Oct (1)	Nov	Dec (21)
2009	Jan	Feb (2)	Mar (1)	Apr	May (1)	Jun (8)	Jul	Aug	Sep	Oct	Nov	Dec
2010	Jan	Feb (1)	Mar (4)	Apr (3)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr (4)	May (19)	Jun (14)	Jul (1)	Aug	Sep	Oct	Nov	Dec
2012	Jan	Feb	Mar (22)	Apr (12)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan (2)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec
2015	Jan	Feb	Mar	Apr	May (3)	Jun	Jul	Aug (2)	Sep	Oct	Nov	Dec (1)
2016	Jan (1)	Feb (1)	Mar	Apr (1)	May	Jun (2)	Jul (1)	Aug	Sep	Oct (1)	Nov (1)	Dec
2017	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

gusdev-gusdev Mailing List for Genomic Unified Schema Development (Page 61)

gusdev-gusdev — Topics concerning GUS development