Menu
▾
▴
gusdev-gusdev — Topics concerning GUS development
You can subscribe to this list here.
| 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
|
|
From: marc j. <de...@ho...> - 2005-01-07 18:04:29
|
<html><div style='background-color:'><DIV class=RTE> <P>Hi Mike, </P> <P>Thanks for the tip. That seems to have done the trick!</P> <P>Regards,</P> <P>Marc<BR><BR></P></DIV> <DIV></DIV>>From: Michael Saffitz <msa...@pc...> <DIV></DIV>>To: marc jackson <de...@ho...> <DIV></DIV>>CC: gus...@li... <DIV></DIV>>Subject: Re: [Gusdev-gusdev] problems loading bootstrap data <DIV></DIV>>Date: Thu, 06 Jan 2005 16:54:32 -0500 <DIV></DIV>> <DIV></DIV>> <DIV></DIV>>Hey Marc, <DIV></DIV>> <DIV></DIV>>This looks like a known Oracle bug in 10g. If it's applicable, log <DIV></DIV>>into metalink, review and apply patch 3612581. <DIV></DIV>> <DIV></DIV>>--Mike <DIV></DIV>> <DIV></DIV>> <DIV></DIV>>marc jackson wrote: <DIV></DIV>>>The command: ga +create GUS::Common::Plugin::UpdateGusFromXML <DIV></DIV>>>--commit <DIV></DIV>>> <DIV></DIV>>>givest: <DIV></DIV>>> <DIV></DIV>>>DBD::Oracle::st execute failed: ORA-00600: internal error code, <DIV></DIV>>>arguments: [kpofdr-long], [], [], [], [], [], [], [] (DBD ERROR: <DIV></DIV>>>error possibly near <*> indicator at char 19 in 'select * from <DIV></DIV>>>Core.<*>AlgorithmImplementation where algorithm_implementation_id <DIV></DIV>>>= :p1') [for Statement "select * from Core.AlgorithmImplementation <DIV></DIV>>>where algorithm_implementation_id = ?" with ParamValues: :p1='21'] <DIV></DIV>>>at /opt/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 251. <DIV></DIV>>>Failed executing: <DIV></DIV>>>select * from Core.AlgorithmImplementation where <DIV></DIV>>>algorithm_implementation_id = ? <DIV></DIV>>> <DIV></DIV>>>with values '21' <DIV></DIV>>>errormsg: ORA-00600: internal error code, arguments: [kpofdr-long], <DIV></DIV>>>[], [], [], [], [], [], [] (DBD ERROR: error possibly near <*> <DIV></DIV>>>indicator at char 19 in 'select * from <DIV></DIV>>>Core.<*>AlgorithmImplementation where algorithm_implementation_id <DIV></DIV>>>= :p1') <DIV></DIV>>> <DIV></DIV>>> <DIV></DIV>>>This means what? <DIV></DIV>>> <DIV></DIV>>>Regards and Thanks! <DIV></DIV>>> <DIV></DIV>>>mj <DIV></DIV>>> <DIV></DIV>>> <DIV></DIV>>> <DIV></DIV>>> <DIV></DIV>>>------------------------------------------------------- <DIV></DIV>>>The SF.Net email is sponsored by: Beat the post-holiday blues <DIV></DIV>>>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. <DIV></DIV>>>It's fun and FREE -- well, <DIV></DIV>>>almost....http://www.thinkgeek.com/sfshirt <DIV></DIV>>>_______________________________________________ <DIV></DIV>>>Gusdev-gusdev mailing list <DIV></DIV>>>Gus...@li... <DIV></DIV>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev <DIV></DIV></div></html> |
|
From: Michael S. <msa...@pc...> - 2005-01-06 21:55:41
|
Hey Marc, This looks like a known Oracle bug in 10g. If it's applicable, log into metalink, review and apply patch 3612581. --Mike marc jackson wrote: > The command: ga +create GUS::Common::Plugin::UpdateGusFromXML --commit > > givest: > > DBD::Oracle::st execute failed: ORA-00600: internal error code, > arguments: [kpofdr-long], [], [], [], [], [], [], [] (DBD ERROR: error > possibly near <*> indicator at char 19 in 'select * from > Core.<*>AlgorithmImplementation where algorithm_implementation_id = > :p1') [for Statement "select * from Core.AlgorithmImplementation where > algorithm_implementation_id = ?" with ParamValues: :p1='21'] at > /opt/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 251. > Failed executing: > select * from Core.AlgorithmImplementation where > algorithm_implementation_id = ? > > with values '21' > errormsg: ORA-00600: internal error code, arguments: [kpofdr-long], [], > [], [], [], [], [], [] (DBD ERROR: error possibly near <*> indicator at > char 19 in 'select * from Core.<*>AlgorithmImplementation where > algorithm_implementation_id = :p1') > > > This means what? > > Regards and Thanks! > > mj > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
|
From: marc j. <de...@ho...> - 2005-01-06 18:53:08
|
The command: ga +create GUS::Common::Plugin::UpdateGusFromXML --commit givest: DBD::Oracle::st execute failed: ORA-00600: internal error code, arguments: [kpofdr-long], [], [], [], [], [], [], [] (DBD ERROR: error possibly near <*> indicator at char 19 in 'select * from Core.<*>AlgorithmImplementation where algorithm_implementation_id = :p1') [for Statement "select * from Core.AlgorithmImplementation where algorithm_implementation_id = ?" with ParamValues: :p1='21'] at /opt/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 251. Failed executing: select * from Core.AlgorithmImplementation where algorithm_implementation_id = ? with values '21' errormsg: ORA-00600: internal error code, arguments: [kpofdr-long], [], [], [], [], [], [], [] (DBD ERROR: error possibly near <*> indicator at char 19 in 'select * from Core.<*>AlgorithmImplementation where algorithm_implementation_id = :p1') This means what? Regards and Thanks! mj |
|
From: marc j. <de...@ho...> - 2005-01-06 17:41:37
|
Hi Steve,
First: cd /opt/gus/sql/B*
Second: ga GUS::Plugin::UpdateGusFromXML
--filename=SRes.ExternalDatabase.xml --commit
The results from the "ga" command:
ERROR: Can't locate object method "new" via package
"GUS::Plugin::UpdateGusFromXML" at (eval 1) line 1.
--------------------------- STACK TRACE -------------------------
GUS::PluginMgr::Plugin::error('GUS::PluginMgr::GusApplication=HASH(0x804c8c4)','Can\'t
locate object method "new" via package "GUS::Plugin::U...') called at
/opt/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 254
GUS::PluginMgr::GusApplication::newFromPluginName('GUS::PluginMgr::GusApplication=HASH(0x804c8c4)','GUS::Plugin::UpdateGusFromXML')
called at /opt/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
398
GUS::PluginMgr::GusApplication::doMajorMode_RunOrReport('GUS::PluginMgr::GusApplication=HASH(0x804c8c4)','GUS::Plugin::UpdateGusFromXML',1)
called at /opt/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
383
GUS::PluginMgr::GusApplication::doMajorMode_Run('GUS::PluginMgr::GusApplication=HASH(0x804c8c4)','GUS::Plugin::UpdateGusFromXML')
called at /opt/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
289
GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x804c8c4)','GUS::Plugin::UpdateGusFromXML')
called at /opt/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
198
GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x804c8c4)','ARRAY(0x805ff68)')
called at /opt/gus/gus_home/bin/ga line 11
Regards,
Marc
>From: Steve Fischer <sfi...@pc...>
>To: marc jackson <de...@ho...>
>CC: gus...@li...
>Subject: Re: [Gusdev-gusdev] installing bootstrap data
>Date: Thu, 06 Jan 2005 12:05:39 -0500
>
>is that the actual error msg? if so, something is suspicious as
>the the package name should be:
> GUS::Common::Plugin::UpdateGusFromXML.
>
>what are you running?
>
>send the stack trace.
>
>steve
>
>marc jackson wrote:
>
>>Hello,
>> I'm installing the bootstrap data into a GUS database. I get the
>>following error message:
>> ERROR: Can't locate object method "new" via package
>>"GUS::Plugin::UpdateGusFromXML" at *eval 1) line 1.
>> There's also a stack trace. Does anyone have any ideas as to why
>>this is happening and how I can fix it?
>> Regards,
>> Marc
>>
>>------------------------------------------------------- The SF.Net
>>email is sponsored by: Beat the post-holiday blues Get a FREE
>>limited edition SourceForge.net t-shirt from ThinkGeek. It's fun
>>and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>>_______________________________________________ Gusdev-gusdev
>>mailing list Gus...@li...
>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
|
|
From: Steve F. <sfi...@pc...> - 2005-01-06 17:05:44
|
is that the actual error msg? if so, something is suspicious as the the package name should be: GUS::Common::Plugin::UpdateGusFromXML. what are you running? send the stack trace. steve marc jackson wrote: > Hello, > > I'm installing the bootstrap data into a GUS database. I get the > following error message: > > ERROR: Can't locate object method "new" via package > "GUS::Plugin::UpdateGusFromXML" at *eval 1) line 1. > > There's also a stack trace. Does anyone have any ideas as to why this > is happening and how I can fix it? > > Regards, > > Marc > > ------------------------------------------------------- The SF.Net > email is sponsored by: Beat the post-holiday blues Get a FREE limited > edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- > well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ Gusdev-gusdev mailing > list Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
|
From: marc j. <de...@ho...> - 2005-01-06 16:16:59
|
<html><div style='background-color:'><DIV class=RTE>Hello,</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>I'm installing the bootstrap data into a GUS database. I get the following error message:</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>ERROR: Can't locate object method "new" via package "GUS::Plugin::UpdateGusFromXML" at *eval 1) line 1.</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>There's also a stack trace. Does anyone have any ideas as to why this is happening and how I can fix it?</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>Regards,</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>Marc<BR><BR></DIV></div></html> |
|
From: Terry C. <tc...@it...> - 2005-01-05 01:06:40
|
Greetings, Curiously, the schema browser shows external_database_release_id in DoTS::NAFeature, but the schema/oracle/dots-views.sql and dots-tables.sql don't have the field (I just checked these out). Is this a crossed wire, or something else? Terry |
|
From: Elisabetta M. <man...@pc...> - 2004-12-23 17:02:59
|
This is an update on my Dec 8 email attached below. We have completed this implementation at CBIL. Here are modifications to the points I had made on my previous email: Point 2. We ended up creating RAD3.AssayAnalysis (linking) table instead of RAD3.StudyAnalysis table. Point 3. We have created this view. Point 5. How to deal with the input LogicalGroup is fairly flexible and different instances of GUS might decide to have different policies. Here is a snapshot of a few initial policies we are using at CBIL to this end: * Input LogicalGroups for DataTransformationResult analyses will not be nested, i.e. no input will be a LogicalGroup consisting itself of LogicalGroups. * For processes which are simple normalizations of a given quantification (or of a pair of quantifications for 2-channel data), the input to the analysis will be just ONE LogicalGroup consisting of that quantification (resp. pair of quantifications). * If the processing is normalization of log ratios in each of TWO 2-channel assays, followed by dye-swap merging, the input will be TWO LogicalGroups, each consisting of 2 quantifications: one logical group for the two samples that represent the numerator in the resulting dye-swap combination and the other for those representing the two samples that represent the denominator. Note that in this scenario we won't be grouping together the 2 quantifications (Cy5 and Cy3) that belong to the same assay. * If the processing is normalization of log ratios in each of n 2-channel assays, the input will be n LogicalGroups, one for each pair of quantifications corresponding to the same assay. Point 6. The AnalysisResultLoader plugin has been modified to deal with the new tables/view created and committed to the GUS/RAD cvs at Sanger. Documentation is at http://www.gusdb.org/documentation/plugins/GUS-RAD-Plugin-AnalysisResultLoader.html Wishing a nice holiday and a happy New Year to everyone, Elisabetta --- On Wed, 8 Dec 2004, Elisabetta Manduchi wrote: > > Here at CBIL we have decided to deprecate the usage of the tables > RAD3.Process*** and to utilize instead a new view of RAD3.AnalysisResultImp > to store the results of a series of DataTransformation protocols. The > Analysis tables were created subsequently to the Process tables and have a > more mature layout, which should facilitate queries. They were originally > created to store down-stream analysis results (e.g. for differential > expression or clustering) but they are also suitable for pre-processing > result storage. > The following describes what we are implementing: > > 1. We have created a RAD3.ProtocolStep table to identify protocols consisting > of an ordered series of (sub) protocols. Every protocol of the latter form is > linked through RAD3.ProtocolStep to its components. Its type will be > "transformation_protocol_series" (DataTransformationProtocolType). > > 2. We'll create a linking table RAD3.StudyAnalysis to facilitate queries. > > 3. We'll create a new view of RAD3.AnalysisResultImp, called > RAD3.DataTransformationResult, which will store all results from a series of > preprocessing steps obtained from protocols with type > DataTransformationProtocolType. This will be a simple view with just 5 > relevant attributes: table_id, row_id (pointing to the spot or to the > probeset on the array; a soft link), and float_value/int_value/string_value > (which will be what's now currently stored in RAD3.ProcessResult.value). > > 4. When a series of processing steps is used, we will only store the results > from the *final* step and the corresponding protocol will be of type > "transformation_protocol_series". > > 5. For processes which are simple normalizations of a given quantification > (or of a pair of quantifications for 2-channel data), the input to the > analysis will be a LogicalGroup consisting just of that quantification (resp. > pair of quantifications). For processes which involve averaging across > quantifications the input LogicalGroup will contain 2 or more quantifications > > 6. In terms of plugins, the current AnalysisResultLoader in the GUS/RAD cvs > repository at Sanger will do. (Enhancements or auxiliary plugins might be > written for the specific case in which the analysis is an up-stream (=low > level=processing) one. So this plugin will do the job that the > ProcessResultLoader was doing for the Process tables.) > > Elisabetta > |
|
From: Jeetendra S. <so...@vb...> - 2004-12-23 15:30:51
|
Michael and All,
I have attached the scripts for Postgresql schema of GUS (with
views defined on Implementation tables). Just modifying and running
create-db.sh script should install the entire schema.
I have tested this schema with a limited number of plugins and
seems to be working ok. I have had to make a few changes to the
schema as and when I found a problem. Therefore, I would request
anyone using this schema to post any problems/bugs that you might
find with the schema.
Michael, I would be glad to have a developer account for GUS CVS. I
would appreciate if you could let me know the procedure for the
same.
Thanks,
Jeetendra.
>
> Jeetendra, Alberto, and all:
>
> First, my apologies for not being more responsive-- I've been
> extraordinarily busy with other matters and haven't had the time or
> opportunity to properly be involved with this work. This work should,
> for the most part, now be complete, and focusing on the Postgres stuff
> is a high priority for me when I return from vacation in early January.
>
> My comments are below.
>
>
> Jeetendra Soneja wrote:
>> Hi Michael,
>>
>> I somehow managed to get a Postgresql version of GUS working,
>> however, this schema is the mirror of the current Oracle GUS schema
>> and not the scripts that were mailed to the list. The project that I
>> am working on requires us to have Postgresql as the backend, and I
>> really wanted something working for the time being. Therefore, I
>> tried to modify a number of things with the Postgresql scripts that
>> you had sent on the list. However, I faced some major issues such as,
>> the inherited tables did not have the primary key contraint defined
>> even though the base table has it.
>
> Yes, this is a limitation, and a serious one at that, that we've
> discovered in Postgres. It (and other issues) have been motivating
> discussions of how we implement inheritance in GUS, and we hope to have
> to a proposal for an alternative to the list sometime in January.
>
> Similarly, they do not inherit the
>> children associated with the base table via foreign key relationship.
>> Even after defining the primary keys and the child relationships for
>> all the inherited tables, it didn't work. I would like to
>> point one more thing here. If we insert a row into the inherited table,
>> although this row does appear in the base table too, this row neither
>> obeys the foreign key contraint nor the primary key constraint that is
>> defined on the base table.
>
> Ultimately, object orientated-ness in both GUS and Oracle appears to be,
> at best, an afterthought. They are very much leveraging the relational
> nature of the system, and as such, a multi-table constraint doesn't fit
> nicely in their paradigm.
>
>> So, finally I generated the Postgresql version of the existing
>> Oracle
>> schema that has views defined on the implementation tables. After
>> this, I generated insert, update and delete rules for all the views.
>
> Good to hear. This is most likely the best option for those that need
> working Postgres instances of GUS today. Would you mind sharing your
> scripts with the list?
>
>> After some modifications to plugins, I have it finally working with
>> the existing gus application. However, I have tested it only with
>> SubmitRow, GBParser, LoadTaxon and LoadBlastSimFast plugins since these
>> are the ones that I will be using the most.
>>
>> Here is the list of issues that I faced while getting the plugins run
>> with
>> Postgresql schema :-
>>
>> --I changed the date field from 'sysdate' to 'now()' in
>> LoadBlastSimFast.pm
>>
>> --In GBParser.pm I changed the following line from
>> $release_date = sysdate;
>> to
>> $release_date = $externalDatabaseRow->getDatabase()->getDateFunction();
>>
>> --Inserted the following lines since in Genbank format, BASE COUNT line
>> is
>> not mandatory and if this line is not present, it gives error on trying
>> to
>> insert emptry string for numeric datatype.
>>
>> $h->{'a_count'} = "null" if(!$h->{'a_count'});
>> $h->{'c_count'} = "null" if(!$h->{'c_count'});
>> $h->{'g_count'} = "null" if(!$h->{'g_count'});
>> $h->{'t_count'} = "null" if(!$h->{'t_count'});
>>
>> --Changed the columns names left to leftcol and right to rightcol for
>> the
>> view RAD3.Scan (and its version table too).
>>
>> --The most significant problem that I faced was with the view columns
>> that
>> are NOT nullable. Is postgresql, even if the actual table has a
>> particular
>> column as NOT NULLABLE, this information is not present in the view
>> description (or its metadata). Therefore, the ViewName_Table.pm modules
>> generated for the views have all the columns as NULLABLE. Therefore, I
>> have just replaced all the '_Table.pm' modules for all the views by the
>> modules generated with the Oracle schema. [Though this is not the
>> correct
>> way, I will have to resort to it for the time being at least. So, rather
>> than building each time, I would just zip the gus-application whereever
>> I
>> need to run it with the postgresql version].
>>
>>
>
> Thanks for all your work-- it's very helpful to us and everyone working
> on the Postgres stuff. We'll need to all work together to ensure that
> the plugins are cross platform, and in cases like the date issue, we'll
> likely need to provide some logic so that they behave properly
> regardless of the underlying RDBMS. Do you have a developer account on
> the GUS CVS?
>
>> Please let me know your suggestions, comments about the same.
>>
>>
>> Thanks a lot,
>> Jeetendra.
>>
>>
>>
>>
>>
>>
>>>Hi Alberto,
>>>
>>>I don't expect to release any new Postgres work until after the first of
>>>the year. The largest issue at this point is how to address subclassing
>>>in GUS and the implementation tables. It's not specific to Postgres--
>>>it's an open area of discussion here at CBIL.
>>>
>>>Continue to follow the GUSDEV list for releases and announcements, and
>>>thanks for the interest.
>>>
>>>--Mike
>>>
>>>
>>>Alberto Davila wrote:
>>>
>>>>Hi Michael, Jeetendra,
>>>>
>>>>Recently one of our students (Pablo Mendes) posted a error log in
>>>> gusdev
>>>>regarding the PostgreSQL version of GUS, but no luck to get any reply
>>>>:-(
>>>>
>>>>I wonder to know any of you would have plans to release a new version
>>>> of
>>>>the PosgreSQL GUS, then we can track it and finish our installation...
>>>>hopefully, this postgreSQL version can help GUS to become more popular,
>>>>then attract more programmers to help with the development/improvement
>>>>of it,
>>>>
>>>>Thanks, Alberto
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>Jeetendra Soneja wrote:
>>>>
>>>>
>>>>>Hi Michael,
>>>>>
>>>>>Thanks for your reply. I had another problem running the plugins using
>>>>>the
>>>>>Postgresql version. I have generated all the objects by following the
>>>>>normal build procedure. However, I am getting the following error
>>>>> while
>>>>>running the plugin:
>>>>>
>>>>>Error: attempting to access a child 'GUS::Model::DoTS::NAEntry' of
>>>>>table
>>>>>'GUS::Model::DoTS::ExternalNASequence' , but that table does not have
>>>>> a
>>>>>child of that type. at
>>>>>/home/soneja.local/gusHomePG/lib/perl/GUS/Model/GusRow.pm line 396,
>>>>><GEN0>
>>>>>line 163.
>>>>>
>>>>>When I opened the automatically generated ExternalNASequence_Table.pm,
>>>>>it's child list is empty.
>>>>>
>>>>>Did I miss something during the build process ?
>>>>>
>>>>>Thank you for your help.
>>>>>
>>>>>Jeetendra.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Jeetendra:
>>>>>>
>>>>>>Jeetendra Soneja wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi Michael,
>>>>>>>
>>>>>>> Thanks for the updates. After downloading the latest code from the
>>>>>>>CVS,
>>>>>>>I was able to register a couple of plugins successfully. Just a
>>>>>>> small
>>>>>>>change while registering GBParser, I had to comment out 'use
>>>>>>>GUS::Model::DoTS::NAFeatureImp' line.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Right, and further, while this technically works in Oracle, it
>>>>>>represents an incorrect usage of the data model: The IMP tables
>>>>>>should
>>>>>>NEVER be used, either directly in SQL queries, nor through the object
>>>>>>layer. Instead, the appropriate superclass should be used
>>>>>>(GUS::Model::DoTS::NAFeature in this case)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I am trying to run GBParser and am having the following problems :-
>>>>>>>
>>>>>>>--An oracle-specific call setOracleDateFormat() in the run mode of
>>>>>>>the
>>>>>>>plugin was causing problems. (For the time being I have commented
>>>>>>> it)
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>In addition, it looks like GBParser uses Oracle's sysdate in setting
>>>>>>the
>>>>>>release date.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>--It's having problems inserting rows into the tables. The value ''
>>>>>>>is
>>>>>>>being inserted into the NUMERIC type columns. Postgresql doesn't
>>>>>>>seem to
>>>>>>>interprete this as a null value, but an emptry string.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Thanks--- This will need to be resolved higher up in the object
>>>>>> layer.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Thank you once again for your help.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Thank you for all your testing!! I have a growing list of issues and
>>>>>>fixes for the Postgres version-- I'll keep this list updated as fixes
>>>>>>are committed to CVS, and please continue to mail the list with your
>>>>>>progress in getting this stuff working.
>>>>>>
>>>>>>--Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Jeetendra.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>All,
>>>>>>>>
>>>>>>>>I've updated DbiDbHandle in CVS to address the capitalization issue
>>>>>>>>(thanks to Angel for the pointer here).
>>>>>>>>
>>>>>>>>This should then allow plugins to be registered with postgres GUS
>>>>>>>>schemas.
>>>>>>>>
>>>>>>>>Just to recap:
>>>>>>>>
>>>>>>>>1) You'll need to use the latest SQL scripts s
> ent by me on 11/30,
>>>>>>>>and
>>>>>>>>the latest CVS (as of now!)
>>>>>>>>2) You'll need to change line 34 of GusApplication such that the
>>>>>>>>requiredDbVersion for Core is 3.0, not 3.
>>>>>>>>3) You'll need to manually add rows as outlined in VBI's GUS
>>>>>>>>installation document. In addition, you'll need to add these rows:
>>>>>>>>
>>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>>VALUES(0,'string',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>>VALUES(1,'float',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>>VALUES(2,'int',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>>VALUES(3,'ref',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>>VALUES(4,'boolean',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>>VALUES(5,'date',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>
>>>>>>>>Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>Jeetendra Soneja wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Hi all,
>>>>>>>>>
>>>>>>>>>The reason that I got errors that I posted earlier was that I did
>>>>>>>>>not
>>>>>>>>>do
>>>>>>>>>a
>>>>>>>>>build. I had just created the Postgresql GUS schema and was trying
>>>>>>>>>to
>>>>>>>>>register the gus application. However, after doing a build, things
>>>>>>>>>worked
>>>>>>>>>out fine.
>>>>>>>>>
>>>>>>>>>I would like to list some of the problems that I have faced till
>>>>>>>>>this
>>>>>>>>>point in using the Postgresql version:-
>>>>>>>>>
>>>>>>>>>-- The rows included in the script gus-rows.pl need a minor
>>>>>>>>>modification.
>>>>>>>>>Values in the rows that are being inserted into core.databaseinfo
>>>>>>>>>need
>>>>>>>>>to
>>>>>>>>>be changed. The names of the schemas CORE, DOTS and SRES should be
>>>>>>>>>changed
>>>>>>>>>Core, DoTS, SRes respectively. Also the values for the version
>>>>>>>>>numbers
>>>>>>>>>should be changed from 1.0 and 3.0 to 1 and 3 respectively.
>>>>>>>>>
>>>>>>>>>-- Currently, I am having trouble registering a plugin (any
>>>>>>>>>plugin). A
>>>>>>>>>number of modules/subroutines are retrieving row as a
>>>>>>>>>hash-reference
>>>>>>>>>and
>>>>>>>>>access a value in a row using key, i.e. column name of the table.
>>>>>>>>>And
>>>>>>>>>all
>>>>>>>>>the keys used in the code are in upper case. This works in case of
>>>>>>>>>oracle,
>>>>>>>>>however, select statements in Postgresql return all the column
>>>>>>>>>names in
>>>>>>>>>lower case. Therefore, in this case, it couldn't find the row for
>>>>>>>>>ga in
>>>>>>>>>the core.algorithmimplementation table (although it's there since
>>>>>>>>> I
>>>>>>>>>have
>>>>>>>>>already registered ga). And when I change the key/column name to
>>>>>>>>>lower
>>>>>>>>>case in GusApplication.pm code, it worked fine.
>>>>>>>>>
>>>>>>>>>I would appreciate any suggestion or comments.
>>>>>>>>>
>>>>>>>>>Thanks a lot,
>>>>>>>>>Jeetendra.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Hi Jeetendra,
>>>>>>>>>>
>>>>>>>>>>Comments below....
>>>>>>>>>>
>>>>>>>>>>Jeetendra Soneja wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Hi Michael,
>>>>>>>>>>> I am glad that the PostgreSQL version has been released.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>This is not an official release!! These are preliminary scripts,
>>>>>>>>>>which
>>>>>>>>>>have had very little testing and are likely to change in the
>>>>>>>>>>future
>>>>>>>>>>(although probably not significantly).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I had a question about using it. Could you tell me if any
>>>>>>>>>>> of
>>>>>>>>>>>the
>>>>>>>>>>>existing plugins (especially those in Common::Plugin) would work
>>>>>>>>>>>with PostgreSQL version of GUS ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>No existing plugins have been tested with PGGUS. Please report
>>>>>>>>>>any
>>>>>>>>>>successes or failures you have to the list.
>>>>>>>>>>
>>>>>>>>>>--Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Thanks,
>>>>>>>>>>>Jeetendra.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>All,
>>>>>>>>>>>>
>>>>>>>>>>>>Postgres GUS scripts are attached. The first, pggus.sql
>>>>>>>>>>>>contains
>>>>>>>>>>>>DDL
>>>>>>>>>>>>for creating GUS tables, indexes, constraints, and sequences.
>>>>>>>>>>>>The
>>>>>>>>>>>>second, gus-rows.sql, contains DML for populating the
>>>>>>>>>>>>core.tableinfo
>>>>>>>>>>>>and
>>>>>>>>>>>>core.databaseinfo tables.
>>>>>>>>>>>>
>>>>>>>>>>>>Consider these early beta-- this is not part of an official
>>>>>>>>>>>>release,
>>>>>>>>>>>>they've had very limited testing, and they are unsupported. In
>>>>>>>>>>>>general
>>>>>>>>>>>>the existing documentation should provide the information
>>>>>>>>>>>>needed to
>>>>>>>>>>>>create an instance with these and GUS with it, but there are
>>>>>>>>>>>>derivations
>>>>>>>>>>>>that will be necessary.
>>>>>>>>>>>>
>>>>>>>>>>>>More information on Postgres and GUS, including an official
>>>>>>>>>>>>release,
>>>>>>>>>>>>should be coming in the next several weeks.
>>>>>>>>>>>>
>>>>>>>>>>>>Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>>Mike
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>-------------------
>>>
>>>------------------------------------
>>>
>>>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>>>>users.
>>>>>>>>Discover which products truly live up to the hype. Start reading
>>>>>>>>now.
>>>>>>>>http://productguide.itmanagersjournal.com/
>>>>>>>>_______________________________________________
>>>>>>>>Gusdev-gusdev mailing list
>>>>>>>>Gus...@li...
>>>>>>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>>users.
>>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>>http://productguide.itmanagersjournal.com/
>>>>>>_______________________________________________
>>>>>>Gusdev-gusdev mailing list
>>>>>>Gus...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
--
Jeetendra Soneja
Research Associate
Virginia Bioinformatics Institute
1880 Pratt Dr., Building XV
Blacksburg, VA 24060, USA
Phone: (540)-231-2789
http://www.vbi.vt.edu |
|
From: davila <da...@io...> - 2004-12-23 11:44:18
|
VGhhbmtzIE1pY2hhZWwsDQogDQpOZXh0IHN0ZXAgKG9uY2Ugd2UgaGF2ZSBtYW5hZ2VkIHRvIGhh dmUgYSBmdWxseSBmdW5jdGlvbmFsIFBvc3RncmVTUUwgdmVyc2lvbiBvZiBHVVMpIGlzIHRvIGhh dmUgYSBmdWxseSBmdW5jdGlvbmFsIHZlcnNpb24gb2YgdGhlIFdESyB3b3JraW5nIHdpdGggaXQu Li4gb3VyIGF0dGVtdHBzIHRvIGluc3RhbGwgdGhlIFdESyAxLjEgZmFpbGVkLCBJIHdpbGwgcG9z dCB0aGUgbG9ncyBhZnRlciB0aGUgYnJlYWsuDQogDQpJIHdvdWxkIGxpa2UgdG8gdGFrZSB0aGUg Y2hhbmNlIHRvIHdpc2ggYWxsIG9mIHlvdSBhIE1lcnJ5IFhtYXMgYW5kIEhhcHB5IE5ldyBZZWFy ICENCiANCktpbmRlc3QgcmVnYXJkcywNCiANCkFsYmVydG8NCg0KCS0tLS0tTWVuc2FnZW0gb3Jp Z2luYWwtLS0tLSANCglEZTogTWljaGFlbCBTYWZmaXR6IFttYWlsdG86bXNhZmZpdHpAcGNiaS51 cGVubi5lZHVdIA0KCUVudmlhZGE6IHF1aSAyMy8xMi8yMDA0IDAyOjExIA0KCVBhcmE6IE1pY2hh ZWwgU2FmZml0eiANCglDYzogSmVldGVuZHJhIFNvbmVqYTsgQWxiZXJ0byBEYXZpbGE7IGd1c2Rl di1ndXNkZXZAbGlzdHMuc291cmNlZm9yZ2UubmV0OyBDaHJpcyBTdG9lY2tlcnQgDQoJQXNzdW50 bzogUmU6IFtHdXNkZXYtZ3VzZGV2XSBQb3N0Z3JlcyBHVVMgU2NyaXB0cw0KCQ0KCQ0KDQoNCglP bmUgcXVpY2sgY2xhcmlmaWNhdGlvbiB0aGF0IENocmlzIGhhcyBicm91Z2h0IHRvIG15IGF0dGVu dGlvbjoNCgkNCglJIHNhaWQ6DQoJDQoJIlVsdGltYXRlbHksIG9iamVjdCBvcmllbnRhdGVkLW5l c3MgaW4gYm90aCBHVVMgYW5kIE9yYWNsZSBhcHBlYXJzIHRvDQoJYmUsIGF0IGJlc3QsIGFuIGFm dGVydGhvdWdodC4gIFRoZXkgYXJlIHZlcnkgbXVjaCBsZXZlcmFnaW5nIHRoZQ0KCXJlbGF0aW9u YWwuLi4iDQoJDQoJVGhpcyBzaG91bGQgaGF2ZSBiZWVuICIuLi4gb2JqZWN0IG9yaWVudGF0ZWQt bmVzcyBpbiBib3RoIFBvc3RncmVzIGFuZA0KCU9yYWNsZSAuLi4iDQoJDQoJQXMgQ2hyaXMgaGFz IHBvaW50ZWQgb3V0LCB0aGUgb2JqZWN0IG9yaWVudGF0ZWQgbmF0dXJlIG9mIEdVUyBoYXMNCgll eGlzdGVkIGZyb20gdGhlIGVhcmxpZXN0IGRheXMgb2YgR1VTLCBhbmQgd2FzIHZlcnkgbXVjaCBj YXJlZnVsbHkNCglwbGFubmVkIGFuZCBpbXBsZW1lbnRlZC4gIEluZGVlZCwgbXVjaCBvZiBHVVMn cyBvYmplY3Qgb3JpZW50YXRlZC1uZXNzDQoJKGZyb20gdGhlIG9iamVjdCBsYXllciB0byBob3cg aW5oZXJpdGFuY2UgaXMgaW1wbGVtZW50ZWQpIHByZWRhdGVzIGFueQ0KCXN1cHBvcnQgT3JhY2xl IG9yIFBvc3RncmVzIGhhZCBmb3Igb2JqZWN0cywgYXMgd2VsbCBhcyBwcmVkYXRpbmcgbWFueQ0K CShpZiBub3QgYWxsKSBvZiB0aGUgb2JqZWN0L3JlbGF0aW9uYWwgbWFwcGluZyB0b29scyBvdXQg dGhlcmUgc3VjaCBhcw0KCUhpYmVybmF0ZS4NCgkNCglTb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbiBh bmQgdW5pbnRlbnRpb25hbCBvZmZlbnNlLg0KCQ0KCS0tTWlrZQ0KCQ0KCQ0KCQ0KCU1pY2hhZWwg U2FmZml0eiB3cm90ZToNCgk+DQoJPiBKZWV0ZW5kcmEsIEFsYmVydG8sIGFuZCBhbGw6DQoJPg0K CT4gRmlyc3QsIG15IGFwb2xvZ2llcyBmb3Igbm90IGJlaW5nIG1vcmUgcmVzcG9uc2l2ZS0tIEkn dmUgYmVlbg0KCT4gZXh0cmFvcmRpbmFyaWx5IGJ1c3kgd2l0aCBvdGhlciBtYXR0ZXJzIGFuZCBo YXZlbid0IGhhZCB0aGUgdGltZSBvcg0KCT4gb3Bwb3J0dW5pdHkgdG8gcHJvcGVybHkgYmUgaW52 b2x2ZWQgd2l0aCB0aGlzIHdvcmsuICBUaGlzIHdvcmsgc2hvdWxkLA0KCT4gZm9yIHRoZSBtb3N0 IHBhcnQsIG5vdyBiZSBjb21wbGV0ZSwgYW5kIGZvY3VzaW5nIG9uIHRoZSBQb3N0Z3JlcyBzdHVm Zg0KCT4gaXMgYSBoaWdoIHByaW9yaXR5IGZvciBtZSB3aGVuIEkgcmV0dXJuIGZyb20gdmFjYXRp b24gaW4gZWFybHkgSmFudWFyeS4NCgk+DQoJPiBNeSBjb21tZW50cyBhcmUgYmVsb3cuDQoJPg0K CT4NCgk+IEplZXRlbmRyYSBTb25lamEgd3JvdGU6DQoJPg0KCT4+IEhpIE1pY2hhZWwsDQoJPj4N Cgk+PiAgICAgIEkgc29tZWhvdyBtYW5hZ2VkIHRvIGdldCBhIFBvc3RncmVzcWwgdmVyc2lvbiBv ZiBHVVMgd29ya2luZywNCgk+PiBob3dldmVyLCB0aGlzIHNjaGVtYSBpcyB0aGUgbWlycm9yIG9m IHRoZSBjdXJyZW50IE9yYWNsZSBHVVMgc2NoZW1hDQoJPj4gYW5kIG5vdCB0aGUgc2NyaXB0cyB0 aGF0IHdlcmUgbWFpbGVkIHRvIHRoZSBsaXN0LiBUaGUgcHJvamVjdCB0aGF0IEkNCgk+PiBhbSB3 b3JraW5nIG9uIHJlcXVpcmVzIHVzIHRvIGhhdmUgUG9zdGdyZXNxbCBhcyB0aGUgYmFja2VuZCwg YW5kIEkNCgk+PiByZWFsbHkgd2FudGVkIHNvbWV0aGluZyB3b3JraW5nIGZvciB0aGUgdGltZSBi ZWluZy4gVGhlcmVmb3JlLCBJDQoJPj4gdHJpZWQgdG8gbW9kaWZ5IGEgbnVtYmVyIG9mIHRoaW5n cyB3aXRoIHRoZSBQb3N0Z3Jlc3FsIHNjcmlwdHMgdGhhdA0KCT4+IHlvdSBoYWQgc2VudCBvbiB0 aGUgbGlzdC4gSG93ZXZlciwgSSBmYWNlZCBzb21lIG1ham9yIGlzc3VlcyBzdWNoIGFzLA0KCT4+ IHRoZSBpbmhlcml0ZWQgdGFibGVzIGRpZCBub3QgaGF2ZSB0aGUgcHJpbWFyeSBrZXkgY29udHJh aW50IGRlZmluZWQNCgk+PiBldmVuIHRob3VnaCB0aGUgYmFzZSB0YWJsZSBoYXMgaXQuDQoJPg0K CT4NCgk+IFllcywgdGhpcyBpcyBhIGxpbWl0YXRpb24sIGFuZCBhIHNlcmlvdXMgb25lIGF0IHRo YXQsIHRoYXQgd2UndmUNCgk+IGRpc2NvdmVyZWQgaW4gUG9zdGdyZXMuICBJdCAoYW5kIG90aGVy IGlzc3VlcykgaGF2ZSBiZWVuIG1vdGl2YXRpbmcNCgk+IGRpc2N1c3Npb25zIG9mIGhvdyB3ZSBp bXBsZW1lbnQgaW5oZXJpdGFuY2UgaW4gR1VTLCBhbmQgd2UgaG9wZSB0byBoYXZlDQoJPiB0byBh IHByb3Bvc2FsIGZvciBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgbGlzdCBzb21ldGltZSBpbiBKYW51 YXJ5Lg0KCT4NCgk+ICBTaW1pbGFybHksIHRoZXkgZG8gbm90IGluaGVyaXQgdGhlDQoJPg0KCT4+ IGNoaWxkcmVuIGFzc29jaWF0ZWQgd2l0aCB0aGUgYmFzZSB0YWJsZSB2aWEgZm9yZWlnbiBrZXkg cmVsYXRpb25zaGlwLg0KCT4+IEV2ZW4gYWZ0ZXIgZGVmaW5pbmcgdGhlIHByaW1hcnkga2V5cyBh bmQgdGhlIGNoaWxkIHJlbGF0aW9uc2hpcHMgZm9yDQoJPj4gYWxsIHRoZSBpbmhlcml0ZWQgdGFi bGVzLCBpdCBkaWRuJ3Qgd29yay4gSSB3b3VsZCBsaWtlIHRvDQoJPj4gcG9pbnQgb25lIG1vcmUg dGhpbmcgaGVyZS4gSWYgd2UgaW5zZXJ0IGEgcm93IGludG8gdGhlIGluaGVyaXRlZCB0YWJsZSwN Cgk+PiBhbHRob3VnaCB0aGlzIHJvdyBkb2VzIGFwcGVhciBpbiB0aGUgYmFzZSB0YWJsZSB0b28s IHRoaXMgcm93IG5laXRoZXINCgk+PiBvYmV5cyB0aGUgZm9yZWlnbiBrZXkgY29udHJhaW50IG5v ciB0aGUgcHJpbWFyeSBrZXkgY29uc3RyYWludCB0aGF0IGlzDQoJPj4gZGVmaW5lZCBvbiB0aGUg YmFzZSB0YWJsZS4NCgk+DQoJPg0KCT4gVWx0aW1hdGVseSwgb2JqZWN0IG9yaWVudGF0ZWQtbmVz cyBpbiBib3RoIEdVUyBhbmQgT3JhY2xlIGFwcGVhcnMgdG8gYmUsDQoJPiBhdCBiZXN0LCBhbiBh ZnRlcnRob3VnaHQuICBUaGV5IGFyZSB2ZXJ5IG11Y2ggbGV2ZXJhZ2luZyB0aGUgcmVsYXRpb25h bA0KCT4gbmF0dXJlIG9mIHRoZSBzeXN0ZW0sIGFuZCBhcyBzdWNoLCBhIG11bHRpLXRhYmxlIGNv bnN0cmFpbnQgZG9lc24ndCBmaXQNCgk+IG5pY2VseSBpbiB0aGVpciBwYXJhZGlnbS4NCgk+DQoJ Pj4gICAgICBTbywgZmluYWxseSBJIGdlbmVyYXRlZCB0aGUgUG9zdGdyZXNxbCB2ZXJzaW9uIG9m IHRoZSBleGlzdGluZw0KCT4+IE9yYWNsZQ0KCT4+IHNjaGVtYSB0aGF0IGhhcyB2aWV3cyBkZWZp bmVkIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiB0YWJsZXMuIEFmdGVyDQoJPj4gdGhpcywgSSBnZW5l cmF0ZWQgaW5zZXJ0LCB1cGRhdGUgYW5kIGRlbGV0ZSBydWxlcyBmb3IgYWxsIHRoZSB2aWV3cy4N Cgk+DQoJPg0KCT4gR29vZCB0byBoZWFyLiAgVGhpcyBpcyBtb3N0IGxpa2VseSB0aGUgYmVzdCBv cHRpb24gZm9yIHRob3NlIHRoYXQgbmVlZA0KCT4gd29ya2luZyBQb3N0Z3JlcyBpbnN0YW5jZXMg b2YgR1VTIHRvZGF5LiAgV291bGQgeW91IG1pbmQgc2hhcmluZyB5b3VyDQoJPiBzY3JpcHRzIHdp dGggdGhlIGxpc3Q/DQoJPg0KCT4+ICAgICAgQWZ0ZXIgc29tZSBtb2RpZmljYXRpb25zIHRvIHBs dWdpbnMsIEkgaGF2ZSBpdCBmaW5hbGx5IHdvcmtpbmcgd2l0aA0KCT4+IHRoZSBleGlzdGluZyBn dXMgYXBwbGljYXRpb24uIEhvd2V2ZXIsIEkgaGF2ZSB0ZXN0ZWQgaXQgb25seSB3aXRoDQoJPj4g U3VibWl0Um93LCBHQlBhcnNlciwgTG9hZFRheG9uIGFuZCBMb2FkQmxhc3RTaW1GYXN0IHBsdWdp bnMgc2luY2UgdGhlc2UNCgk+PiBhcmUgdGhlIG9uZXMgdGhhdCBJIHdpbGwgYmUgdXNpbmcgdGhl IG1vc3QuDQoJPj4NCgk+PiBIZXJlIGlzIHRoZSBsaXN0IG9mIGlzc3VlcyB0aGF0IEkgZmFjZWQg d2hpbGUgZ2V0dGluZyB0aGUgcGx1Z2lucyBydW4NCgk+PiB3aXRoDQoJPj4gUG9zdGdyZXNxbCBz Y2hlbWEgOi0NCgk+Pg0KCT4+IC0tSSBjaGFuZ2VkIHRoZSBkYXRlIGZpZWxkIGZyb20gJ3N5c2Rh dGUnIHRvICdub3coKScgaW4NCgk+PiBMb2FkQmxhc3RTaW1GYXN0LnBtDQoJPj4NCgk+PiAtLUlu IEdCUGFyc2VyLnBtIEkgY2hhbmdlZCB0aGUgZm9sbG93aW5nIGxpbmUgZnJvbQ0KCT4+ICRyZWxl YXNlX2RhdGUgPSBzeXNkYXRlOw0KCT4+IHRvDQoJPj4gJHJlbGVhc2VfZGF0ZSA9ICRleHRlcm5h bERhdGFiYXNlUm93LT5nZXREYXRhYmFzZSgpLT5nZXREYXRlRnVuY3Rpb24oKTsNCgk+Pg0KCT4+ IC0tSW5zZXJ0ZWQgdGhlIGZvbGxvd2luZyBsaW5lcyBzaW5jZSBpbiBHZW5iYW5rIGZvcm1hdCwg QkFTRSBDT1VOVA0KCT4+IGxpbmUgaXMNCgk+PiBub3QgbWFuZGF0b3J5IGFuZCBpZiB0aGlzIGxp bmUgaXMgbm90IHByZXNlbnQsIGl0IGdpdmVzIGVycm9yIG9uDQoJPj4gdHJ5aW5nIHRvDQoJPj4g aW5zZXJ0IGVtcHRyeSBzdHJpbmcgZm9yIG51bWVyaWMgZGF0YXR5cGUuDQoJPj4NCgk+PiAgICRo LT57J2FfY291bnQnfSA9ICJudWxsIiBpZighJGgtPnsnYV9jb3VudCd9KTsNCgk+PiAgICRoLT57 J2NfY291bnQnfSA9ICJudWxsIiBpZighJGgtPnsnY19jb3VudCd9KTsNCgk+PiAgICRoLT57J2df Y291bnQnfSA9ICJudWxsIiBpZighJGgtPnsnZ19jb3VudCd9KTsNCgk+PiAgICRoLT57J3RfY291 bnQnfSA9ICJudWxsIiBpZighJGgtPnsndF9jb3VudCd9KTsNCgk+Pg0KCT4+IC0tQ2hhbmdlZCB0 aGUgY29sdW1ucyBuYW1lcyBsZWZ0IHRvIGxlZnRjb2wgYW5kIHJpZ2h0IHRvIHJpZ2h0Y29sIGZv ciB0aGUNCgk+PiB2aWV3IFJBRDMuU2NhbiAoYW5kIGl0cyB2ZXJzaW9uIHRhYmxlIHRvbykuDQoJ Pj4NCgk+PiAtLVRoZSBtb3N0IHNpZ25pZmljYW50IHByb2JsZW0gdGhhdCBJIGZhY2VkIHdhcyB3 aXRoIHRoZSB2aWV3IGNvbHVtbnMNCgk+PiB0aGF0DQoJPj4gYXJlIE5PVCBudWxsYWJsZS4gSXMg cG9zdGdyZXNxbCwgZXZlbiBpZiB0aGUgYWN0dWFsIHRhYmxlIGhhcyBhDQoJPj4gcGFydGljdWxh cg0KCT4+IGNvbHVtbiBhcyBOT1QgTlVMTEFCTEUsIHRoaXMgaW5mb3JtYXRpb24gaXMgbm90IHBy ZXNlbnQgaW4gdGhlIHZpZXcNCgk+PiBkZXNjcmlwdGlvbiAob3IgaXRzIG1ldGFkYXRhKS4gVGhl cmVmb3JlLCB0aGUgVmlld05hbWVfVGFibGUucG0gbW9kdWxlcw0KCT4+IGdlbmVyYXRlZCBmb3Ig dGhlIHZpZXdzIGhhdmUgYWxsIHRoZSBjb2x1bW5zIGFzIE5VTExBQkxFLiBUaGVyZWZvcmUsIEkN Cgk+PiBoYXZlIGp1c3QgcmVwbGFjZWQgYWxsIHRoZSAnX1RhYmxlLnBtJyBtb2R1bGVzIGZvciBh bGwgdGhlIHZpZXdzIGJ5IHRoZQ0KCT4+IG1vZHVsZXMgZ2VuZXJhdGVkIHdpdGggdGhlIE9yYWNs ZSBzY2hlbWEuIFtUaG91Z2ggdGhpcyBpcyBub3QgdGhlIGNvcnJlY3QNCgk+PiB3YXksIEkgd2ls bCBoYXZlIHRvIHJlc29ydCB0byBpdCBmb3IgdGhlIHRpbWUgYmVpbmcgYXQgbGVhc3QuIFNvLCBy YXRoZXINCgk+PiB0aGFuIGJ1aWxkaW5nIGVhY2ggdGltZSwgSSB3b3VsZCBqdXN0IHppcCB0aGUg Z3VzLWFwcGxpY2F0aW9uIHdoZXJlZXZlciBJDQoJPj4gbmVlZCB0byBydW4gaXQgd2l0aCB0aGUg cG9zdGdyZXNxbCB2ZXJzaW9uXS4NCgk+Pg0KCT4+DQoJPg0KCT4gVGhhbmtzIGZvciBhbGwgeW91 ciB3b3JrLS0gaXQncyB2ZXJ5IGhlbHBmdWwgdG8gdXMgYW5kIGV2ZXJ5b25lIHdvcmtpbmcNCgk+ IG9uIHRoZSBQb3N0Z3JlcyBzdHVmZi4gIFdlJ2xsIG5lZWQgdG8gYWxsIHdvcmsgdG9nZXRoZXIg dG8gZW5zdXJlIHRoYXQNCgk+IHRoZSBwbHVnaW5zIGFyZSBjcm9zcyBwbGF0Zm9ybSwgYW5kIGlu IGNhc2VzIGxpa2UgdGhlIGRhdGUgaXNzdWUsIHdlJ2xsDQoJPiBsaWtlbHkgbmVlZCB0byBwcm92 aWRlIHNvbWUgbG9naWMgc28gdGhhdCB0aGV5IGJlaGF2ZSBwcm9wZXJseQ0KCT4gcmVnYXJkbGVz cyBvZiB0aGUgdW5kZXJseWluZyBSREJNUy4gIERvIHlvdSBoYXZlIGEgZGV2ZWxvcGVyIGFjY291 bnQgb24NCgk+IHRoZSBHVVMgQ1ZTPw0KCT4NCgk+PiBQbGVhc2UgbGV0IG1lIGtub3cgeW91ciBz dWdnZXN0aW9ucywgY29tbWVudHMgYWJvdXQgdGhlIHNhbWUuDQoJPj4NCgk+Pg0KCT4+IFRoYW5r cyBhIGxvdCwNCgk+PiBKZWV0ZW5kcmEuDQoJPj4NCgk+Pg0KCT4+DQoJPj4NCgk+Pg0KCT4+DQoJ Pj4+IEhpIEFsYmVydG8sDQoJPj4+DQoJPj4+IEkgZG9uJ3QgZXhwZWN0IHRvIHJlbGVhc2UgYW55 IG5ldyBQb3N0Z3JlcyB3b3JrIHVudGlsIGFmdGVyIHRoZSBmaXJzdCBvZg0KCT4+PiB0aGUgeWVh ci4gIFRoZSBsYXJnZXN0IGlzc3VlIGF0IHRoaXMgcG9pbnQgaXMgaG93IHRvIGFkZHJlc3Mgc3Vi Y2xhc3NpbmcNCgk+Pj4gaW4gR1VTIGFuZCB0aGUgaW1wbGVtZW50YXRpb24gdGFibGVzLiAgSXQn cyBub3Qgc3BlY2lmaWMgdG8gUG9zdGdyZXMtLQ0KCT4+PiBpdCdzIGFuIG9wZW4gYXJlYSBvZiBk aXNjdXNzaW9uIGhlcmUgYXQgQ0JJTC4NCgk+Pj4NCgk+Pj4gQ29udGludWUgdG8gZm9sbG93IHRo ZSBHVVNERVYgbGlzdCBmb3IgcmVsZWFzZXMgYW5kIGFubm91bmNlbWVudHMsIGFuZA0KCT4+PiB0 aGFua3MgZm9yIHRoZSBpbnRlcmVzdC4NCgk+Pj4NCgk+Pj4gLS1NaWtlDQoJPj4+DQoJPj4+DQoJ Pj4+IEFsYmVydG8gRGF2aWxhIHdyb3RlOg0KCT4+Pg0KCT4+Pj4gSGkgTWljaGFlbCwgSmVldGVu ZHJhLA0KCT4+Pj4NCgk+Pj4+IFJlY2VudGx5IG9uZSBvZiBvdXIgc3R1ZGVudHMgKFBhYmxvIE1l bmRlcykgcG9zdGVkIGEgZXJyb3IgbG9nIGluDQoJPj4+PiBndXNkZXYNCgk+Pj4+IHJlZ2FyZGlu ZyB0aGUgUG9zdGdyZVNRTCB2ZXJzaW9uIG9mIEdVUywgYnV0IG5vIGx1Y2sgdG8gZ2V0IGFueSBy ZXBseQ0KCT4+Pj4gOi0oDQoJPj4+Pg0KCT4+Pj4gSSB3b25kZXIgdG8ga25vdyBhbnkgb2YgeW91 IHdvdWxkIGhhdmUgcGxhbnMgdG8gcmVsZWFzZSBhIG5ldw0KCT4+Pj4gdmVyc2lvbiBvZg0KCT4+ Pj4gdGhlIFBvc2dyZVNRTCBHVVMsIHRoZW4gd2UgY2FuIHRyYWNrIGl0IGFuZCBmaW5pc2ggb3Vy IGluc3RhbGxhdGlvbi4uLg0KCT4+Pj4gaG9wZWZ1bGx5LCB0aGlzIHBvc3RncmVTUUwgdmVyc2lv biBjYW4gaGVscCBHVVMgdG8gYmVjb21lIG1vcmUgcG9wdWxhciwNCgk+Pj4+IHRoZW4gYXR0cmFj dCBtb3JlIHByb2dyYW1tZXJzIHRvIGhlbHAgd2l0aCB0aGUgZGV2ZWxvcG1lbnQvaW1wcm92ZW1l bnQNCgk+Pj4+IG9mIGl0LA0KCT4+Pj4NCgk+Pj4+IFRoYW5rcywgQWxiZXJ0bw0KCT4+Pj4NCgk+ Pj4+DQoJPj4+Pg0KCT4+Pj4NCgk+Pj4+DQoJPj4+PiBKZWV0ZW5kcmEgU29uZWphIHdyb3RlOg0K CT4+Pj4NCgk+Pj4+DQoJPj4+Pj4gSGkgTWljaGFlbCwNCgk+Pj4+Pg0KCT4+Pj4+IFRoYW5rcyBm b3IgeW91ciByZXBseS4gSSBoYWQgYW5vdGhlciBwcm9ibGVtIHJ1bm5pbmcgdGhlIHBsdWdpbnMg dXNpbmcNCgk+Pj4+PiB0aGUNCgk+Pj4+PiBQb3N0Z3Jlc3FsIHZlcnNpb24uIEkgaGF2ZSBnZW5l cmF0ZWQgYWxsIHRoZSBvYmplY3RzIGJ5IGZvbGxvd2luZyB0aGUNCgk+Pj4+PiBub3JtYWwgYnVp bGQgcHJvY2VkdXJlLiBIb3dldmVyLCBJIGFtIGdldHRpbmcgdGhlIGZvbGxvd2luZyBlcnJvcg0K CT4+Pj4+IHdoaWxlDQoJPj4+Pj4gcnVubmluZyB0aGUgcGx1Z2luOg0KCT4+Pj4+DQoJPj4+Pj4g RXJyb3I6ICBhdHRlbXB0aW5nIHRvIGFjY2VzcyBhIGNoaWxkICdHVVM6Ok1vZGVsOjpEb1RTOjpO QUVudHJ5JyBvZg0KCT4+Pj4+IHRhYmxlDQoJPj4+Pj4gJ0dVUzo6TW9kZWw6OkRvVFM6OkV4dGVy bmFsTkFTZXF1ZW5jZScgLCBidXQgdGhhdCB0YWJsZSBkb2VzIG5vdA0KCT4+Pj4+IGhhdmUgYQ0K CT4+Pj4+IGNoaWxkIG9mIHRoYXQgdHlwZS4gYXQNCgk+Pj4+PiAvaG9tZS9zb25lamEubG9jYWwv Z3VzSG9tZVBHL2xpYi9wZXJsL0dVUy9Nb2RlbC9HdXNSb3cucG0gbGluZSAzOTYsDQoJPj4+Pj4g PEdFTjA+DQoJPj4+Pj4gbGluZSAxNjMuDQoJPj4+Pj4NCgk+Pj4+PiBXaGVuIEkgb3BlbmVkIHRo ZSBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBFeHRlcm5hbE5BU2VxdWVuY2VfVGFibGUucG0sDQoJ Pj4+Pj4gaXQncyBjaGlsZCBsaXN0IGlzIGVtcHR5Lg0KCT4+Pj4+DQoJPj4+Pj4gRGlkIEkgbWlz cyBzb21ldGhpbmcgZHVyaW5nIHRoZSBidWlsZCBwcm9jZXNzID8NCgk+Pj4+Pg0KCT4+Pj4+IFRo YW5rIHlvdSBmb3IgeW91ciBoZWxwLg0KCT4+Pj4+DQoJPj4+Pj4gSmVldGVuZHJhLg0KCT4+Pj4+ DQoJPj4+Pj4NCgk+Pj4+Pg0KCT4+Pj4+DQoJPj4+Pj4NCgk+Pj4+Pg0KCT4+Pj4+DQoJPj4+Pj4N Cgk+Pj4+Pj4gSGkgSmVldGVuZHJhOg0KCT4+Pj4+Pg0KCT4+Pj4+PiBKZWV0ZW5kcmEgU29uZWph IHdyb3RlOg0KCT4+Pj4+Pg0KCT4+Pj4+Pg0KCT4+Pj4+Pg0KCT4+Pj4+Pj4gSGkgTWljaGFlbCwN Cgk+Pj4+Pj4+DQoJPj4+Pj4+PiAgVGhhbmtzIGZvciB0aGUgdXBkYXRlcy4gQWZ0ZXIgZG93bmxv YWRpbmcgdGhlIGxhdGVzdCBjb2RlIGZyb20gdGhlDQoJPj4+Pj4+PiBDVlMsDQoJPj4+Pj4+PiBJ IHdhcyBhYmxlIHRvIHJlZ2lzdGVyIGEgY291cGxlIG9mIHBsdWdpbnMgc3VjY2Vzc2Z1bGx5LiBK dXN0IGENCgk+Pj4+Pj4+IHNtYWxsDQoJPj4+Pj4+PiBjaGFuZ2Ugd2hpbGUgcmVnaXN0ZXJpbmcg R0JQYXJzZXIsIEkgaGFkIHRvIGNvbW1lbnQgb3V0ICd1c2UNCgk+Pj4+Pj4+IEdVUzo6TW9kZWw6 OkRvVFM6Ok5BRmVhdHVyZUltcCcgbGluZS4NCgk+Pj4+Pj4+DQoJPj4+Pj4+Pg0KCT4+Pj4+Pg0K CT4+Pj4+PiBSaWdodCwgYW5kIGZ1cnRoZXIsIHdoaWxlIHRoaXMgdGVjaG5pY2FsbHkgd29ya3Mg aW4gT3JhY2xlLCBpdA0KCT4+Pj4+PiByZXByZXNlbnRzIGFuIGluY29ycmVjdCB1c2FnZSBvZiB0 aGUgZGF0YSBtb2RlbDogIFRoZSBJTVAgdGFibGVzDQoJPj4+Pj4+IHNob3VsZA0KCT4+Pj4+PiBO RVZFUiBiZSB1c2VkLCBlaXRoZXIgZGlyZWN0bHkgaW4gU1FMIHF1ZXJpZXMsIG5vciB0aHJvdWdo IHRoZSBvYmplY3QNCgk+Pj4+Pj4gbGF5ZXIuICBJbnN0ZWFkLCB0aGUgYXBwcm9wcmlhdGUgc3Vw ZXJjbGFzcyBzaG91bGQgYmUgdXNlZA0KCT4+Pj4+PiAoR1VTOjpNb2RlbDo6RG9UUzo6TkFGZWF0 dXJlIGluIHRoaXMgY2FzZSkNCgk+Pj4+Pj4NCgk+Pj4+Pj4NCgk+Pj4+Pj4NCgk+Pj4+Pj4NCgk+ Pj4+Pj4+IEkgYW0gdHJ5aW5nIHRvIHJ1biBHQlBhcnNlciBhbmQgYW0gaGF2aW5nIHRoZSBmb2xs b3dpbmcgcHJvYmxlbXMgOi0NCgk+Pj4+Pj4+DQoJPj4+Pj4+PiAtLUFuIG9yYWNsZS1zcGVjaWZp YyBjYWxsIHNldE9yYWNsZURhdGVGb3JtYXQoKSBpbiB0aGUgcnVuIG1vZGUgb2YNCgk+Pj4+Pj4+ IHRoZQ0KCT4+Pj4+Pj4gcGx1Z2luIHdhcyBjYXVzaW5nIHByb2JsZW1zLiAoRm9yIHRoZSB0aW1l IGJlaW5nIEkgaGF2ZSBjb21tZW50ZWQNCgk+Pj4+Pj4+IGl0KQ0KCT4+Pj4+Pj4NCgk+Pj4+Pj4+ DQoJPj4+Pj4+DQoJPj4+Pj4+IEluIGFkZGl0aW9uLCBpdCBsb29rcyBsaWtlIEdCUGFyc2VyIHVz ZXMgT3JhY2xlJ3Mgc3lzZGF0ZSBpbiBzZXR0aW5nDQoJPj4+Pj4+IHRoZQ0KCT4+Pj4+PiByZWxl YXNlIGRhdGUuDQoJPj4+Pj4+DQoJPj4+Pj4+DQoJPj4+Pj4+DQoJPj4+Pj4+DQoJPj4+Pj4+PiAt LUl0J3MgaGF2aW5nIHByb2JsZW1zIGluc2VydGluZyByb3dzIGludG8gdGhlIHRhYmxlcy4gVGhl IHZhbHVlICcnDQoJPj4+Pj4+PiBpcw0KCT4+Pj4+Pj4gYmVpbmcgaW5zZXJ0ZWQgaW50byB0aGUg TlVNRVJJQyB0eXBlIGNvbHVtbnMuIFBvc3RncmVzcWwgZG9lc24ndA0KCT4+Pj4+Pj4gc2VlbSB0 bw0KCT4+Pj4+Pj4gaW50ZXJwcmV0ZSB0aGlzIGFzIGEgbnVsbCB2YWx1ZSwgYnV0IGFuIGVtcHRy eSBzdHJpbmcuDQoJPj4+Pj4+Pg0KCT4+Pj4+Pj4NCgk+Pj4+Pj4NCgk+Pj4+Pj4gVGhhbmtzLS0t IFRoaXMgd2lsbCBuZWVkIHRvIGJlIHJlc29sdmVkIGhpZ2hlciB1cCBpbiB0aGUgb2JqZWN0DQoJ Pj4+Pj4+IGxheWVyLg0KCT4+Pj4+Pg0KCT4+Pj4+Pg0KCT4+Pj4+Pg0KCT4+Pj4+Pg0KCT4+Pj4+ Pj4gVGhhbmsgeW91IG9uY2UgYWdhaW4gZm9yIHlvdXIgaGVscC4NCgk+Pj4+Pj4+DQoJPj4+Pj4+ Pg0KCT4+Pj4+Pg0KCT4+Pj4+PiBUaGFuayB5b3UgZm9yIGFsbCB5b3VyIHRlc3RpbmchISAgSSBo YXZlIGEgZ3Jvd2luZyBsaXN0IG9mIGlzc3VlcyBhbmQNCgk+Pj4+Pj4gZml4ZXMgZm9yIHRoZSBQ b3N0Z3JlcyB2ZXJzaW9uLS0gSSdsbCBrZWVwIHRoaXMgbGlzdCB1cGRhdGVkIGFzIGZpeGVzDQoJ Pj4+Pj4+IGFyZSBjb21taXR0ZWQgdG8gQ1ZTLCBhbmQgcGxlYXNlIGNvbnRpbnVlIHRvIG1haWwg dGhlIGxpc3Qgd2l0aCB5b3VyDQoJPj4+Pj4+IHByb2dyZXNzIGluIGdldHRpbmcgdGhpcyBzdHVm ZiB3b3JraW5nLg0KCT4+Pj4+Pg0KCT4+Pj4+PiAtLU1pa2UNCgk+Pj4+Pj4NCgk+Pj4+Pj4NCgk+ Pj4+Pj4NCgk+Pj4+Pj4NCgk+Pj4+Pj4+IEplZXRlbmRyYS4NCgk+Pj4+Pj4+DQoJPj4+Pj4+Pg0K CT4+Pj4+Pj4NCgk+Pj4+Pj4+DQoJPj4+Pj4+Pg0KCT4+Pj4+Pj4NCgk+Pj4+Pj4+DQoJPj4+Pj4+ Pg0KCT4+Pj4+Pj4NCgk+Pj4+Pj4+DQoJPj4+Pj4+Pj4gQWxsLA0KCT4+Pj4+Pj4+DQoJPj4+Pj4+ Pj4gSSd2ZSB1cGRhdGVkIERiaURiSGFuZGxlIGluIENWUyB0byBhZGRyZXNzIHRoZSBjYXBpdGFs aXphdGlvbiBpc3N1ZQ0KCT4+Pj4+Pj4+ICh0aGFua3MgdG8gQW5nZWwgZm9yIHRoZSBwb2ludGVy IGhlcmUpLg0KCT4+Pj4+Pj4+DQoJPj4+Pj4+Pj4gVGhpcyBzaG91bGQgdGhlbiBhbGxvdyBwbHVn aW5zIHRvIGJlIHJlZ2lzdGVyZWQgd2l0aCBwb3N0Z3JlcyBHVVMNCgk+Pj4+Pj4+PiBzY2hlbWFz Lg0KCT4+Pj4+Pj4+DQoJPj4+Pj4+Pj4gSnVzdCB0byByZWNhcDoNCgk+Pj4+Pj4+Pg0KCT4+Pj4+ Pj4+IDEpIFlvdSdsbCBuZWVkIHRvIHVzZSB0aGUgbGF0ZXN0IFNRTCBzY3JpcHRzIHNlbnQgYnkg bWUgb24gMTEvMzAsDQoJPj4+Pj4+Pj4gYW5kDQoJPj4+Pj4+Pj4gdGhlIGxhdGVzdCBDVlMgKGFz IG9mIG5vdyEpDQoJPj4+Pj4+Pj4gMikgWW91J2xsIG5lZWQgdG8gY2hhbmdlIGxpbmUgMzQgb2Yg R3VzQXBwbGljYXRpb24gc3VjaCB0aGF0IHRoZQ0KCT4+Pj4+Pj4+IHJlcXVpcmVkRGJWZXJzaW9u IGZvciBDb3JlIGlzIDMuMCwgbm90IDMuDQoJPj4+Pj4+Pj4gMykgWW91J2xsIG5lZWQgdG8gbWFu dWFsbHkgYWRkIHJvd3MgYXMgb3V0bGluZWQgaW4gVkJJJ3MgR1VTDQoJPj4+Pj4+Pj4gaW5zdGFs bGF0aW9uIGRvY3VtZW50LiAgSW4gYWRkaXRpb24sIHlvdSdsbCBuZWVkIHRvIGFkZCB0aGVzZSBy b3dzOg0KCT4+Pj4+Pj4+DQoJPj4+Pj4+Pj4gSU5TRVJUIElOVE8gQ29yZS5BbGdvcml0aG1QYXJh bUtleVR5cGUNCgk+Pj4+Pj4+PiBWQUxVRVMoMCwnc3RyaW5nJyxub3coKSwxLDEsMSwxLDEsMCwx LCAxLCAxLCAxKTsNCgk+Pj4+Pj4+PiBJTlNFUlQgSU5UTyBDb3JlLkFsZ29yaXRobVBhcmFtS2V5 VHlwZQ0KCT4+Pj4+Pj4+IFZBTFVFUygxLCdmbG9hdCcsbm93KCksMSwxLDEsMSwxLDAsMSwgMSwg MSwgMSk7DQoJPj4+Pj4+Pj4gSU5TRVJUIElOVE8gQ29yZS5BbGdvcml0aG1QYXJhbUtleVR5cGUN Cgk+Pj4+Pj4+PiBWQUxVRVMoMiwnaW50Jyxub3coKSwxLDEsMSwxLDEsMCwxLCAxLCAxLCAxKTsN Cgk+Pj4+Pj4+PiBJTlNFUlQgSU5UTyBDb3JlLkFsZ29yaXRobVBhcmFtS2V5VHlwZQ0KCT4+Pj4+ Pj4+IFZBTFVFUygzLCdyZWYnLG5vdygpLDEsMSwxLDEsMSwwLDEsIDEsIDEsIDEpOw0KCT4+Pj4+ Pj4+IElOU0VSVCBJTlRPIENvcmUuQWxnb3JpdGhtUGFyYW1LZXlUeXBlDQoJPj4+Pj4+Pj4gVkFM VUVTKDQsJ2Jvb2xlYW4nLG5vdygpLDEsMSwxLDEsMSwwLDEsIDEsIDEsIDEpOw0KCT4+Pj4+Pj4+ IElOU0VSVCBJTlRPIENvcmUuQWxnb3JpdGhtUGFyYW1LZXlUeXBlDQoJPj4+Pj4+Pj4gVkFMVUVT KDUsJ2RhdGUnLG5vdygpLDEsMSwxLDEsMSwwLDEsIDEsIDEsIDEpOw0KCT4+Pj4+Pj4+DQoJPj4+ Pj4+Pj4gVGhhbmtzLA0KCT4+Pj4+Pj4+DQoJPj4+Pj4+Pj4gTWlrZQ0KCT4+Pj4+Pj4+DQoJPj4+ Pj4+Pj4NCgk+Pj4+Pj4+PiBKZWV0ZW5kcmEgU29uZWphIHdyb3RlOg0KCT4+Pj4+Pj4+DQoJPj4+ Pj4+Pj4NCgk+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+IEhpIGFsbCwNCgk+Pj4+Pj4+ Pj4NCgk+Pj4+Pj4+Pj4gVGhlIHJlYXNvbiB0aGF0IEkgZ290IGVycm9ycyB0aGF0IEkgcG9zdGVk IGVhcmxpZXIgd2FzIHRoYXQgSSBkaWQNCgk+Pj4+Pj4+Pj4gbm90DQoJPj4+Pj4+Pj4+IGRvDQoJ Pj4+Pj4+Pj4+IGENCgk+Pj4+Pj4+Pj4gYnVpbGQuIEkgaGFkIGp1c3QgY3JlYXRlZCB0aGUgUG9z dGdyZXNxbCBHVVMgc2NoZW1hIGFuZCB3YXMgdHJ5aW5nDQoJPj4+Pj4+Pj4+IHRvDQoJPj4+Pj4+ Pj4+IHJlZ2lzdGVyIHRoZSBndXMgYXBwbGljYXRpb24uIEhvd2V2ZXIsIGFmdGVyIGRvaW5nIGEg YnVpbGQsIHRoaW5ncw0KCT4+Pj4+Pj4+PiB3b3JrZWQNCgk+Pj4+Pj4+Pj4gb3V0IGZpbmUuDQoJ Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+IEkgd291bGQgbGlrZSB0byBsaXN0IHNvbWUgb2YgdGhlIHBy b2JsZW1zIHRoYXQgSSBoYXZlIGZhY2VkIHRpbGwNCgk+Pj4+Pj4+Pj4gdGhpcw0KCT4+Pj4+Pj4+ PiBwb2ludCBpbiB1c2luZyB0aGUgUG9zdGdyZXNxbCB2ZXJzaW9uOi0NCgk+Pj4+Pj4+Pj4NCgk+ Pj4+Pj4+Pj4gLS0gVGhlIHJvd3MgaW5jbHVkZWQgaW4gdGhlIHNjcmlwdCBndXMtcm93cy5wbCBu ZWVkIGEgbWlub3INCgk+Pj4+Pj4+Pj4gbW9kaWZpY2F0aW9uLg0KCT4+Pj4+Pj4+PiBWYWx1ZXMg aW4gdGhlIHJvd3MgdGhhdCBhcmUgYmVpbmcgaW5zZXJ0ZWQgaW50byBjb3JlLmRhdGFiYXNlaW5m bw0KCT4+Pj4+Pj4+PiBuZWVkDQoJPj4+Pj4+Pj4+IHRvDQoJPj4+Pj4+Pj4+IGJlIGNoYW5nZWQu IFRoZSBuYW1lcyBvZiB0aGUgc2NoZW1hcyBDT1JFLCBET1RTIGFuZCBTUkVTIHNob3VsZCBiZQ0K CT4+Pj4+Pj4+PiBjaGFuZ2VkDQoJPj4+Pj4+Pj4+IENvcmUsIERvVFMsIFNSZXMgcmVzcGVjdGl2 ZWx5LiBBbHNvIHRoZSB2YWx1ZXMgZm9yIHRoZSB2ZXJzaW9uDQoJPj4+Pj4+Pj4+IG51bWJlcnMN Cgk+Pj4+Pj4+Pj4gc2hvdWxkIGJlIGNoYW5nZWQgZnJvbSAxLjAgYW5kIDMuMCB0byAxIGFuZCAz IHJlc3BlY3RpdmVseS4NCgk+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4gLS0gQ3VycmVudGx5LCBJIGFt IGhhdmluZyB0cm91YmxlIHJlZ2lzdGVyaW5nIGEgcGx1Z2luIChhbnkNCgk+Pj4+Pj4+Pj4gcGx1 Z2luKS4gQQ0KCT4+Pj4+Pj4+PiBudW1iZXIgb2YgbW9kdWxlcy9zdWJyb3V0aW5lcyBhcmUgcmV0 cmlldmluZyByb3cgYXMgYQ0KCT4+Pj4+Pj4+PiBoYXNoLXJlZmVyZW5jZQ0KCT4+Pj4+Pj4+PiBh bmQNCgk+Pj4+Pj4+Pj4gYWNjZXNzIGEgdmFsdWUgaW4gYSByb3cgdXNpbmcga2V5LCBpLmUuIGNv bHVtbiBuYW1lIG9mIHRoZSB0YWJsZS4NCgk+Pj4+Pj4+Pj4gQW5kDQoJPj4+Pj4+Pj4+IGFsbA0K CT4+Pj4+Pj4+PiB0aGUga2V5cyB1c2VkIGluIHRoZSBjb2RlIGFyZSBpbiB1cHBlciBjYXNlLiBU aGlzIHdvcmtzIGluIGNhc2Ugb2YNCgk+Pj4+Pj4+Pj4gb3JhY2xlLA0KCT4+Pj4+Pj4+PiBob3dl dmVyLCBzZWxlY3Qgc3RhdGVtZW50cyBpbiBQb3N0Z3Jlc3FsIHJldHVybiBhbGwgdGhlIGNvbHVt bg0KCT4+Pj4+Pj4+PiBuYW1lcyBpbg0KCT4+Pj4+Pj4+PiBsb3dlciBjYXNlLiBUaGVyZWZvcmUs IGluIHRoaXMgY2FzZSwgaXQgY291bGRuJ3QgZmluZCB0aGUgcm93IGZvcg0KCT4+Pj4+Pj4+PiBn YSBpbg0KCT4+Pj4+Pj4+PiB0aGUgY29yZS5hbGdvcml0aG1pbXBsZW1lbnRhdGlvbiB0YWJsZSAo YWx0aG91Z2ggaXQncyB0aGVyZQ0KCT4+Pj4+Pj4+PiBzaW5jZSBJDQoJPj4+Pj4+Pj4+IGhhdmUN Cgk+Pj4+Pj4+Pj4gYWxyZWFkeSByZWdpc3RlcmVkIGdhKS4gQW5kIHdoZW4gSSBjaGFuZ2UgdGhl IGtleS9jb2x1bW4gbmFtZSB0bw0KCT4+Pj4+Pj4+PiBsb3dlcg0KCT4+Pj4+Pj4+PiBjYXNlIGlu IEd1c0FwcGxpY2F0aW9uLnBtIGNvZGUsIGl0IHdvcmtlZCBmaW5lLg0KCT4+Pj4+Pj4+Pg0KCT4+ Pj4+Pj4+PiBJIHdvdWxkIGFwcHJlY2lhdGUgYW55IHN1Z2dlc3Rpb24gb3IgY29tbWVudHMuDQoJ Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+IFRoYW5rcyBhIGxvdCwNCgk+Pj4+Pj4+Pj4gSmVldGVuZHJh Lg0KCT4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pg0KCT4+Pj4+ Pj4+Pg0KCT4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pg0KCT4+ Pj4+Pj4+Pj4gSGkgSmVldGVuZHJhLA0KCT4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+IENvbW1lbnRz IGJlbG93Li4uLg0KCT4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+IEplZXRlbmRyYSBTb25lamEgd3Jv dGU6DQoJPj4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pg0K CT4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+PiBIaSBNaWNoYWVsLA0KCT4+Pj4+Pj4+Pj4+ICAgICBJ IGFtIGdsYWQgdGhhdCB0aGUgUG9zdGdyZVNRTCB2ZXJzaW9uIGhhcyBiZWVuIHJlbGVhc2VkLg0K CT4+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+PiBUaGlz IGlzIG5vdCBhbiBvZmZpY2lhbCByZWxlYXNlISEgIFRoZXNlIGFyZSBwcmVsaW1pbmFyeSBzY3Jp cHRzLA0KCT4+Pj4+Pj4+Pj4gd2hpY2gNCgk+Pj4+Pj4+Pj4+IGhhdmUgaGFkIHZlcnkgbGl0dGxl IHRlc3RpbmcgYW5kIGFyZSBsaWtlbHkgdG8gY2hhbmdlIGluIHRoZQ0KCT4+Pj4+Pj4+Pj4gZnV0 dXJlDQoJPj4+Pj4+Pj4+PiAoYWx0aG91Z2ggcHJvYmFibHkgbm90IHNpZ25pZmljYW50bHkpLg0K CT4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pj4NCgk+Pj4+ Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pj4+ICAgICBJIGhhZCBhIHF1ZXN0aW9uIGFi b3V0IHVzaW5nIGl0LiBDb3VsZCB5b3UgdGVsbCBtZSBpZiBhbnkgb2YNCgk+Pj4+Pj4+Pj4+PiB0 aGUNCgk+Pj4+Pj4+Pj4+PiBleGlzdGluZyBwbHVnaW5zIChlc3BlY2lhbGx5IHRob3NlIGluIENv bW1vbjo6UGx1Z2luKSB3b3VsZCB3b3JrDQoJPj4+Pj4+Pj4+Pj4gd2l0aCBQb3N0Z3JlU1FMIHZl cnNpb24gb2YgR1VTID8NCgk+Pj4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pg0K CT4+Pj4+Pj4+Pj4gTm8gZXhpc3RpbmcgcGx1Z2lucyBoYXZlIGJlZW4gdGVzdGVkIHdpdGggUEdH VVMuICBQbGVhc2UgcmVwb3J0DQoJPj4+Pj4+Pj4+PiBhbnkNCgk+Pj4+Pj4+Pj4+IHN1Y2Nlc3Nl cyBvciBmYWlsdXJlcyB5b3UgaGF2ZSB0byB0aGUgbGlzdC4NCgk+Pj4+Pj4+Pj4+DQoJPj4+Pj4+ Pj4+PiAtLU1pa2UNCgk+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pj4NCgk+Pj4+ Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+PiBUaGFua3MsDQoJ Pj4+Pj4+Pj4+Pj4gSmVldGVuZHJhLg0KCT4+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pj4NCgk+Pj4+ Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+Pg0KCT4+Pj4+ Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+Pg0KCT4+Pj4+Pj4+Pj4+PiBBbGwsDQoJ Pj4+Pj4+Pj4+Pj4+DQoJPj4+Pj4+Pj4+Pj4+IFBvc3RncmVzIEdVUyBzY3JpcHRzIGFyZSBhdHRh Y2hlZC4gIFRoZSBmaXJzdCwgcGdndXMuc3FsDQoJPj4+Pj4+Pj4+Pj4+IGNvbnRhaW5zDQoJPj4+ Pj4+Pj4+Pj4+IERETA0KCT4+Pj4+Pj4+Pj4+PiBmb3IgY3JlYXRpbmcgR1VTIHRhYmxlcywgaW5k ZXhlcywgY29uc3RyYWludHMsIGFuZCBzZXF1ZW5jZXMuDQoJPj4+Pj4+Pj4+Pj4+IFRoZQ0KCT4+ Pj4+Pj4+Pj4+PiBzZWNvbmQsIGd1cy1yb3dzLnNxbCwgY29udGFpbnMgRE1MIGZvciBwb3B1bGF0 aW5nIHRoZQ0KCT4+Pj4+Pj4+Pj4+PiBjb3JlLnRhYmxlaW5mbw0KCT4+Pj4+Pj4+Pj4+PiBhbmQN Cgk+Pj4+Pj4+Pj4+Pj4gY29yZS5kYXRhYmFzZWluZm8gdGFibGVzLg0KCT4+Pj4+Pj4+Pj4+Pg0K CT4+Pj4+Pj4+Pj4+PiBDb25zaWRlciB0aGVzZSBlYXJseSBiZXRhLS0gdGhpcyBpcyBub3QgcGFy dCBvZiBhbiBvZmZpY2lhbA0KCT4+Pj4+Pj4+Pj4+PiByZWxlYXNlLA0KCT4+Pj4+Pj4+Pj4+PiB0 aGV5J3ZlIGhhZCB2ZXJ5IGxpbWl0ZWQgdGVzdGluZywgYW5kIHRoZXkgYXJlIHVuc3VwcG9ydGVk LiAgSW4NCgk+Pj4+Pj4+Pj4+Pj4gZ2VuZXJhbA0KCT4+Pj4+Pj4+Pj4+PiB0aGUgZXhpc3Rpbmcg ZG9jdW1lbnRhdGlvbiBzaG91bGQgcHJvdmlkZSB0aGUgaW5mb3JtYXRpb24NCgk+Pj4+Pj4+Pj4+ Pj4gbmVlZGVkIHRvDQoJPj4+Pj4+Pj4+Pj4+IGNyZWF0ZSBhbiBpbnN0YW5jZSB3aXRoIHRoZXNl IGFuZCBHVVMgd2l0aCBpdCwgYnV0IHRoZXJlIGFyZQ0KCT4+Pj4+Pj4+Pj4+PiBkZXJpdmF0aW9u cw0KCT4+Pj4+Pj4+Pj4+PiB0aGF0IHdpbGwgYmUgbmVjZXNzYXJ5Lg0KCT4+Pj4+Pj4+Pj4+Pg0K CT4+Pj4+Pj4+Pj4+PiBNb3JlIGluZm9ybWF0aW9uIG9uIFBvc3RncmVzIGFuZCBHVVMsIGluY2x1 ZGluZyBhbiBvZmZpY2lhbA0KCT4+Pj4+Pj4+Pj4+PiByZWxlYXNlLA0KCT4+Pj4+Pj4+Pj4+PiBz aG91bGQgYmUgY29taW5nIGluIHRoZSBuZXh0IHNldmVyYWwgd2Vla3MuDQoJPj4+Pj4+Pj4+Pj4+ DQoJPj4+Pj4+Pj4+Pj4+IFRoYW5rcywNCgk+Pj4+Pj4+Pj4+Pj4NCgk+Pj4+Pj4+Pj4+Pj4gTWlr ZQ0KCQ0KDQo= |
|
From: Elisabetta M. <man...@pc...> - 2004-12-23 11:32:10
|
Hi, things are back to normal now. I had already rebuilt the objects and the schema browser on Tuesday, then noticed that it was pointing to CBILPROD instead of CBILBLD and sent an email to Steve with questions, but he is away so I figured we had to wait a bit. In any case, now that Mike has switched things back to CBILBLD, I can see the doc and the also the new tables and doc. Thanks, Elisabetta P.S. Thomas there should be no table called ArrayAnalysis There is a new table called AssayAnalysis in RAD3, but it's kosher, it is in TableInfo and the doc is now visible. --- On Wed, 22 Dec 2004 msa...@pc... wrote: > > All, > > The schema browser had been switched to work with CBILPROD for the duration of > the database changes. I've changed it back to CBILBLD, so a rebuild of the > objects for it should hopefully resolve the issue (which I haven't done). > > --Mike > > Quoting "Y. Thomas Gan" <yg...@pc...>: > >> I do not know the exactly cause, but I do not think it is caused by the db >> upgrades (which has been the culprit frequently these several days ;-). >> The browser works fine on some tables - even some RAD3 tables. >> >> According to the server log, the browser is trying to add "ArrayAnalysis" >> to the child list of "Array" and that fails. Is ArrayAnalysis a new table in >> RAD3? Is read permission granted? I could not see this table from my >> personal login. The table is not in core.tableInfo or all_tables. The case >> for Quantification is the same except the problem table is >> "ProbeProfiler". Ring any bells to anyone? >> >> -Thomas >> >> On Wed, 22 Dec 2004, Elisabetta Manduchi wrote: >> >>> >>> We have had some db upgrades that might have affected this. >>> The people that can help with this are currently on vacation, so I imagine >>> they will address it after the holiday break. >>> Sorry for the inconvenience, >>> Elisabetta >>> --- >>> >>> On Wed, 22 Dec 2004, Sucheta Tripathy wrote: >>> >>>> I am sorry for this kind off the track question . I was trying to look >> into >>>> RAD3.assay, RAD3.quantification through the schema browser, but could not >>>> open it. >>>> >>>> Is there a problem? or my computer has it? >>>> >>>> Thanks >>>> >>>> Sucheta >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> SF email is sponsored by - The IT Product Guide >>>> Read honest & candid reviews on hundreds of IT Products from real users. >>>> Discover which products truly live up to the hype. Start reading now. >>>> http://productguide.itmanagersjournal.com/ >>>> _______________________________________________ >>>> Gusdev-gusdev mailing list >>>> Gus...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >>>> >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://productguide.itmanagersjournal.com/ >>> _______________________________________________ >>> Gusdev-gusdev mailing list >>> Gus...@li... >>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >>> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://productguide.itmanagersjournal.com/ >> _______________________________________________ >> Gusdev-gusdev mailing list >> Gus...@li... >> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >> > |
|
From: Michael S. <msa...@pc...> - 2004-12-23 04:12:09
|
One quick clarification that Chris has brought to my attention:
I said:
"Ultimately, object orientated-ness in both GUS and Oracle appears to
be, at best, an afterthought. They are very much leveraging the
relational..."
This should have been "... object orientated-ness in both Postgres and
Oracle ..."
As Chris has pointed out, the object orientated nature of GUS has
existed from the earliest days of GUS, and was very much carefully
planned and implemented. Indeed, much of GUS's object orientated-ness
(from the object layer to how inheritance is implemented) predates any
support Oracle or Postgres had for objects, as well as predating many
(if not all) of the object/relational mapping tools out there such as
Hibernate.
Sorry for the confusion and unintentional offense.
--Mike
Michael Saffitz wrote:
>
> Jeetendra, Alberto, and all:
>
> First, my apologies for not being more responsive-- I've been
> extraordinarily busy with other matters and haven't had the time or
> opportunity to properly be involved with this work. This work should,
> for the most part, now be complete, and focusing on the Postgres stuff
> is a high priority for me when I return from vacation in early January.
>
> My comments are below.
>
>
> Jeetendra Soneja wrote:
>
>> Hi Michael,
>>
>> I somehow managed to get a Postgresql version of GUS working,
>> however, this schema is the mirror of the current Oracle GUS schema
>> and not the scripts that were mailed to the list. The project that I
>> am working on requires us to have Postgresql as the backend, and I
>> really wanted something working for the time being. Therefore, I
>> tried to modify a number of things with the Postgresql scripts that
>> you had sent on the list. However, I faced some major issues such as,
>> the inherited tables did not have the primary key contraint defined
>> even though the base table has it.
>
>
> Yes, this is a limitation, and a serious one at that, that we've
> discovered in Postgres. It (and other issues) have been motivating
> discussions of how we implement inheritance in GUS, and we hope to have
> to a proposal for an alternative to the list sometime in January.
>
> Similarly, they do not inherit the
>
>> children associated with the base table via foreign key relationship.
>> Even after defining the primary keys and the child relationships for
>> all the inherited tables, it didn't work. I would like to
>> point one more thing here. If we insert a row into the inherited table,
>> although this row does appear in the base table too, this row neither
>> obeys the foreign key contraint nor the primary key constraint that is
>> defined on the base table.
>
>
> Ultimately, object orientated-ness in both GUS and Oracle appears to be,
> at best, an afterthought. They are very much leveraging the relational
> nature of the system, and as such, a multi-table constraint doesn't fit
> nicely in their paradigm.
>
>> So, finally I generated the Postgresql version of the existing
>> Oracle
>> schema that has views defined on the implementation tables. After
>> this, I generated insert, update and delete rules for all the views.
>
>
> Good to hear. This is most likely the best option for those that need
> working Postgres instances of GUS today. Would you mind sharing your
> scripts with the list?
>
>> After some modifications to plugins, I have it finally working with
>> the existing gus application. However, I have tested it only with
>> SubmitRow, GBParser, LoadTaxon and LoadBlastSimFast plugins since these
>> are the ones that I will be using the most.
>>
>> Here is the list of issues that I faced while getting the plugins run
>> with
>> Postgresql schema :-
>>
>> --I changed the date field from 'sysdate' to 'now()' in
>> LoadBlastSimFast.pm
>>
>> --In GBParser.pm I changed the following line from
>> $release_date = sysdate;
>> to
>> $release_date = $externalDatabaseRow->getDatabase()->getDateFunction();
>>
>> --Inserted the following lines since in Genbank format, BASE COUNT
>> line is
>> not mandatory and if this line is not present, it gives error on
>> trying to
>> insert emptry string for numeric datatype.
>>
>> $h->{'a_count'} = "null" if(!$h->{'a_count'});
>> $h->{'c_count'} = "null" if(!$h->{'c_count'});
>> $h->{'g_count'} = "null" if(!$h->{'g_count'});
>> $h->{'t_count'} = "null" if(!$h->{'t_count'});
>>
>> --Changed the columns names left to leftcol and right to rightcol for the
>> view RAD3.Scan (and its version table too).
>>
>> --The most significant problem that I faced was with the view columns
>> that
>> are NOT nullable. Is postgresql, even if the actual table has a
>> particular
>> column as NOT NULLABLE, this information is not present in the view
>> description (or its metadata). Therefore, the ViewName_Table.pm modules
>> generated for the views have all the columns as NULLABLE. Therefore, I
>> have just replaced all the '_Table.pm' modules for all the views by the
>> modules generated with the Oracle schema. [Though this is not the correct
>> way, I will have to resort to it for the time being at least. So, rather
>> than building each time, I would just zip the gus-application whereever I
>> need to run it with the postgresql version].
>>
>>
>
> Thanks for all your work-- it's very helpful to us and everyone working
> on the Postgres stuff. We'll need to all work together to ensure that
> the plugins are cross platform, and in cases like the date issue, we'll
> likely need to provide some logic so that they behave properly
> regardless of the underlying RDBMS. Do you have a developer account on
> the GUS CVS?
>
>> Please let me know your suggestions, comments about the same.
>>
>>
>> Thanks a lot,
>> Jeetendra.
>>
>>
>>
>>
>>
>>
>>> Hi Alberto,
>>>
>>> I don't expect to release any new Postgres work until after the first of
>>> the year. The largest issue at this point is how to address subclassing
>>> in GUS and the implementation tables. It's not specific to Postgres--
>>> it's an open area of discussion here at CBIL.
>>>
>>> Continue to follow the GUSDEV list for releases and announcements, and
>>> thanks for the interest.
>>>
>>> --Mike
>>>
>>>
>>> Alberto Davila wrote:
>>>
>>>> Hi Michael, Jeetendra,
>>>>
>>>> Recently one of our students (Pablo Mendes) posted a error log in
>>>> gusdev
>>>> regarding the PostgreSQL version of GUS, but no luck to get any reply
>>>> :-(
>>>>
>>>> I wonder to know any of you would have plans to release a new
>>>> version of
>>>> the PosgreSQL GUS, then we can track it and finish our installation...
>>>> hopefully, this postgreSQL version can help GUS to become more popular,
>>>> then attract more programmers to help with the development/improvement
>>>> of it,
>>>>
>>>> Thanks, Alberto
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Jeetendra Soneja wrote:
>>>>
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Thanks for your reply. I had another problem running the plugins using
>>>>> the
>>>>> Postgresql version. I have generated all the objects by following the
>>>>> normal build procedure. However, I am getting the following error
>>>>> while
>>>>> running the plugin:
>>>>>
>>>>> Error: attempting to access a child 'GUS::Model::DoTS::NAEntry' of
>>>>> table
>>>>> 'GUS::Model::DoTS::ExternalNASequence' , but that table does not
>>>>> have a
>>>>> child of that type. at
>>>>> /home/soneja.local/gusHomePG/lib/perl/GUS/Model/GusRow.pm line 396,
>>>>> <GEN0>
>>>>> line 163.
>>>>>
>>>>> When I opened the automatically generated ExternalNASequence_Table.pm,
>>>>> it's child list is empty.
>>>>>
>>>>> Did I miss something during the build process ?
>>>>>
>>>>> Thank you for your help.
>>>>>
>>>>> Jeetendra.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Jeetendra:
>>>>>>
>>>>>> Jeetendra Soneja wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> Thanks for the updates. After downloading the latest code from the
>>>>>>> CVS,
>>>>>>> I was able to register a couple of plugins successfully. Just a
>>>>>>> small
>>>>>>> change while registering GBParser, I had to comment out 'use
>>>>>>> GUS::Model::DoTS::NAFeatureImp' line.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Right, and further, while this technically works in Oracle, it
>>>>>> represents an incorrect usage of the data model: The IMP tables
>>>>>> should
>>>>>> NEVER be used, either directly in SQL queries, nor through the object
>>>>>> layer. Instead, the appropriate superclass should be used
>>>>>> (GUS::Model::DoTS::NAFeature in this case)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I am trying to run GBParser and am having the following problems :-
>>>>>>>
>>>>>>> --An oracle-specific call setOracleDateFormat() in the run mode of
>>>>>>> the
>>>>>>> plugin was causing problems. (For the time being I have commented
>>>>>>> it)
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> In addition, it looks like GBParser uses Oracle's sysdate in setting
>>>>>> the
>>>>>> release date.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> --It's having problems inserting rows into the tables. The value ''
>>>>>>> is
>>>>>>> being inserted into the NUMERIC type columns. Postgresql doesn't
>>>>>>> seem to
>>>>>>> interprete this as a null value, but an emptry string.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks--- This will need to be resolved higher up in the object
>>>>>> layer.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thank you once again for your help.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thank you for all your testing!! I have a growing list of issues and
>>>>>> fixes for the Postgres version-- I'll keep this list updated as fixes
>>>>>> are committed to CVS, and please continue to mail the list with your
>>>>>> progress in getting this stuff working.
>>>>>>
>>>>>> --Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Jeetendra.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I've updated DbiDbHandle in CVS to address the capitalization issue
>>>>>>>> (thanks to Angel for the pointer here).
>>>>>>>>
>>>>>>>> This should then allow plugins to be registered with postgres GUS
>>>>>>>> schemas.
>>>>>>>>
>>>>>>>> Just to recap:
>>>>>>>>
>>>>>>>> 1) You'll need to use the latest SQL scripts sent by me on 11/30,
>>>>>>>> and
>>>>>>>> the latest CVS (as of now!)
>>>>>>>> 2) You'll need to change line 34 of GusApplication such that the
>>>>>>>> requiredDbVersion for Core is 3.0, not 3.
>>>>>>>> 3) You'll need to manually add rows as outlined in VBI's GUS
>>>>>>>> installation document. In addition, you'll need to add these rows:
>>>>>>>>
>>>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>> VALUES(0,'string',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>> VALUES(1,'float',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>> VALUES(2,'int',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>> VALUES(3,'ref',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>> VALUES(4,'boolean',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>> VALUES(5,'date',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>> Jeetendra Soneja wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> The reason that I got errors that I posted earlier was that I did
>>>>>>>>> not
>>>>>>>>> do
>>>>>>>>> a
>>>>>>>>> build. I had just created the Postgresql GUS schema and was trying
>>>>>>>>> to
>>>>>>>>> register the gus application. However, after doing a build, things
>>>>>>>>> worked
>>>>>>>>> out fine.
>>>>>>>>>
>>>>>>>>> I would like to list some of the problems that I have faced till
>>>>>>>>> this
>>>>>>>>> point in using the Postgresql version:-
>>>>>>>>>
>>>>>>>>> -- The rows included in the script gus-rows.pl need a minor
>>>>>>>>> modification.
>>>>>>>>> Values in the rows that are being inserted into core.databaseinfo
>>>>>>>>> need
>>>>>>>>> to
>>>>>>>>> be changed. The names of the schemas CORE, DOTS and SRES should be
>>>>>>>>> changed
>>>>>>>>> Core, DoTS, SRes respectively. Also the values for the version
>>>>>>>>> numbers
>>>>>>>>> should be changed from 1.0 and 3.0 to 1 and 3 respectively.
>>>>>>>>>
>>>>>>>>> -- Currently, I am having trouble registering a plugin (any
>>>>>>>>> plugin). A
>>>>>>>>> number of modules/subroutines are retrieving row as a
>>>>>>>>> hash-reference
>>>>>>>>> and
>>>>>>>>> access a value in a row using key, i.e. column name of the table.
>>>>>>>>> And
>>>>>>>>> all
>>>>>>>>> the keys used in the code are in upper case. This works in case of
>>>>>>>>> oracle,
>>>>>>>>> however, select statements in Postgresql return all the column
>>>>>>>>> names in
>>>>>>>>> lower case. Therefore, in this case, it couldn't find the row for
>>>>>>>>> ga in
>>>>>>>>> the core.algorithmimplementation table (although it's there
>>>>>>>>> since I
>>>>>>>>> have
>>>>>>>>> already registered ga). And when I change the key/column name to
>>>>>>>>> lower
>>>>>>>>> case in GusApplication.pm code, it worked fine.
>>>>>>>>>
>>>>>>>>> I would appreciate any suggestion or comments.
>>>>>>>>>
>>>>>>>>> Thanks a lot,
>>>>>>>>> Jeetendra.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Jeetendra,
>>>>>>>>>>
>>>>>>>>>> Comments below....
>>>>>>>>>>
>>>>>>>>>> Jeetendra Soneja wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Michael,
>>>>>>>>>>> I am glad that the PostgreSQL version has been released.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is not an official release!! These are preliminary scripts,
>>>>>>>>>> which
>>>>>>>>>> have had very little testing and are likely to change in the
>>>>>>>>>> future
>>>>>>>>>> (although probably not significantly).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I had a question about using it. Could you tell me if any of
>>>>>>>>>>> the
>>>>>>>>>>> existing plugins (especially those in Common::Plugin) would work
>>>>>>>>>>> with PostgreSQL version of GUS ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No existing plugins have been tested with PGGUS. Please report
>>>>>>>>>> any
>>>>>>>>>> successes or failures you have to the list.
>>>>>>>>>>
>>>>>>>>>> --Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Jeetendra.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> All,
>>>>>>>>>>>>
>>>>>>>>>>>> Postgres GUS scripts are attached. The first, pggus.sql
>>>>>>>>>>>> contains
>>>>>>>>>>>> DDL
>>>>>>>>>>>> for creating GUS tables, indexes, constraints, and sequences.
>>>>>>>>>>>> The
>>>>>>>>>>>> second, gus-rows.sql, contains DML for populating the
>>>>>>>>>>>> core.tableinfo
>>>>>>>>>>>> and
>>>>>>>>>>>> core.databaseinfo tables.
>>>>>>>>>>>>
>>>>>>>>>>>> Consider these early beta-- this is not part of an official
>>>>>>>>>>>> release,
>>>>>>>>>>>> they've had very limited testing, and they are unsupported. In
>>>>>>>>>>>> general
>>>>>>>>>>>> the existing documentation should provide the information
>>>>>>>>>>>> needed to
>>>>>>>>>>>> create an instance with these and GUS with it, but there are
>>>>>>>>>>>> derivations
>>>>>>>>>>>> that will be necessary.
>>>>>>>>>>>>
>>>>>>>>>>>> More information on Postgres and GUS, including an official
>>>>>>>>>>>> release,
>>>>>>>>>>>> should be coming in the next several weeks.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> -------------------
>>>
>>>
>>> ------------------------------------
>>>
>>>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>>>> Read honest & candid reviews on hundreds of IT Products from real
>>>>>>>> users.
>>>>>>>> Discover which products truly live up to the hype. Start reading
>>>>>>>> now.
>>>>>>>> http://productguide.itmanagersjournal.com/
>>>>>>>> _______________________________________________
>>>>>>>> Gusdev-gusdev mailing list
>>>>>>>> Gus...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>> Read honest & candid reviews on hundreds of IT Products from real
>>>>>> users.
>>>>>> Discover which products truly live up to the hype. Start reading now.
>>>>>> http://productguide.itmanagersjournal.com/
>>>>>> _______________________________________________
>>>>>> Gusdev-gusdev mailing list
>>>>>> Gus...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
|
|
From: <msa...@pc...> - 2004-12-23 03:24:33
|
All, The schema browser had been switched to work with CBILPROD for the duration of the database changes. I've changed it back to CBILBLD, so a rebuild of the objects for it should hopefully resolve the issue (which I haven't done). --Mike Quoting "Y. Thomas Gan" <yg...@pc...>: > I do not know the exactly cause, but I do not think it is caused by the db > upgrades (which has been the culprit frequently these several days ;-). > The browser works fine on some tables - even some RAD3 tables. > > According to the server log, the browser is trying to add "ArrayAnalysis" > to the child list of "Array" and that fails. Is ArrayAnalysis a new table in > RAD3? Is read permission granted? I could not see this table from my > personal login. The table is not in core.tableInfo or all_tables. The case > for Quantification is the same except the problem table is > "ProbeProfiler". Ring any bells to anyone? > > -Thomas > > On Wed, 22 Dec 2004, Elisabetta Manduchi wrote: > > > > > We have had some db upgrades that might have affected this. > > The people that can help with this are currently on vacation, so I imagine > > they will address it after the holiday break. > > Sorry for the inconvenience, > > Elisabetta > > --- > > > > On Wed, 22 Dec 2004, Sucheta Tripathy wrote: > > > >> I am sorry for this kind off the track question . I was trying to look > into > >> RAD3.assay, RAD3.quantification through the schema browser, but could not > >> open it. > >> > >> Is there a problem? or my computer has it? > >> > >> Thanks > >> > >> Sucheta > >> > >> > >> > >> ------------------------------------------------------- > >> SF email is sponsored by - The IT Product Guide > >> Read honest & candid reviews on hundreds of IT Products from real users. > >> Discover which products truly live up to the hype. Start reading now. > >> http://productguide.itmanagersjournal.com/ > >> _______________________________________________ > >> Gusdev-gusdev mailing list > >> Gus...@li... > >> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > >> > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > Gusdev-gusdev mailing list > > Gus...@li... > > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > |
|
From: Y. T. G. <yg...@pc...> - 2004-12-23 03:09:28
|
I do not know the exactly cause, but I do not think it is caused by the db upgrades (which has been the culprit frequently these several days ;-). The browser works fine on some tables - even some RAD3 tables. According to the server log, the browser is trying to add "ArrayAnalysis" to the child list of "Array" and that fails. Is ArrayAnalysis a new table in RAD3? Is read permission granted? I could not see this table from my personal login. The table is not in core.tableInfo or all_tables. The case for Quantification is the same except the problem table is "ProbeProfiler". Ring any bells to anyone? -Thomas On Wed, 22 Dec 2004, Elisabetta Manduchi wrote: > > We have had some db upgrades that might have affected this. > The people that can help with this are currently on vacation, so I imagine > they will address it after the holiday break. > Sorry for the inconvenience, > Elisabetta > --- > > On Wed, 22 Dec 2004, Sucheta Tripathy wrote: > >> I am sorry for this kind off the track question . I was trying to look into >> RAD3.assay, RAD3.quantification through the schema browser, but could not >> open it. >> >> Is there a problem? or my computer has it? >> >> Thanks >> >> Sucheta >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://productguide.itmanagersjournal.com/ >> _______________________________________________ >> Gusdev-gusdev mailing list >> Gus...@li... >> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > |
|
From: Michael S. <msa...@pc...> - 2004-12-23 00:03:09
|
Jeetendra, Alberto, and all:
First, my apologies for not being more responsive-- I've been
extraordinarily busy with other matters and haven't had the time or
opportunity to properly be involved with this work. This work should,
for the most part, now be complete, and focusing on the Postgres stuff
is a high priority for me when I return from vacation in early January.
My comments are below.
Jeetendra Soneja wrote:
> Hi Michael,
>
> I somehow managed to get a Postgresql version of GUS working,
> however, this schema is the mirror of the current Oracle GUS schema
> and not the scripts that were mailed to the list. The project that I
> am working on requires us to have Postgresql as the backend, and I
> really wanted something working for the time being. Therefore, I
> tried to modify a number of things with the Postgresql scripts that
> you had sent on the list. However, I faced some major issues such as,
> the inherited tables did not have the primary key contraint defined
> even though the base table has it.
Yes, this is a limitation, and a serious one at that, that we've
discovered in Postgres. It (and other issues) have been motivating
discussions of how we implement inheritance in GUS, and we hope to have
to a proposal for an alternative to the list sometime in January.
Similarly, they do not inherit the
> children associated with the base table via foreign key relationship.
> Even after defining the primary keys and the child relationships for
> all the inherited tables, it didn't work. I would like to
> point one more thing here. If we insert a row into the inherited table,
> although this row does appear in the base table too, this row neither
> obeys the foreign key contraint nor the primary key constraint that is
> defined on the base table.
Ultimately, object orientated-ness in both GUS and Oracle appears to be,
at best, an afterthought. They are very much leveraging the relational
nature of the system, and as such, a multi-table constraint doesn't fit
nicely in their paradigm.
> So, finally I generated the Postgresql version of the existing Oracle
> schema that has views defined on the implementation tables. After
> this, I generated insert, update and delete rules for all the views.
Good to hear. This is most likely the best option for those that need
working Postgres instances of GUS today. Would you mind sharing your
scripts with the list?
> After some modifications to plugins, I have it finally working with
> the existing gus application. However, I have tested it only with
> SubmitRow, GBParser, LoadTaxon and LoadBlastSimFast plugins since these
> are the ones that I will be using the most.
>
> Here is the list of issues that I faced while getting the plugins run with
> Postgresql schema :-
>
> --I changed the date field from 'sysdate' to 'now()' in LoadBlastSimFast.pm
>
> --In GBParser.pm I changed the following line from
> $release_date = sysdate;
> to
> $release_date = $externalDatabaseRow->getDatabase()->getDateFunction();
>
> --Inserted the following lines since in Genbank format, BASE COUNT line is
> not mandatory and if this line is not present, it gives error on trying to
> insert emptry string for numeric datatype.
>
> $h->{'a_count'} = "null" if(!$h->{'a_count'});
> $h->{'c_count'} = "null" if(!$h->{'c_count'});
> $h->{'g_count'} = "null" if(!$h->{'g_count'});
> $h->{'t_count'} = "null" if(!$h->{'t_count'});
>
> --Changed the columns names left to leftcol and right to rightcol for the
> view RAD3.Scan (and its version table too).
>
> --The most significant problem that I faced was with the view columns that
> are NOT nullable. Is postgresql, even if the actual table has a particular
> column as NOT NULLABLE, this information is not present in the view
> description (or its metadata). Therefore, the ViewName_Table.pm modules
> generated for the views have all the columns as NULLABLE. Therefore, I
> have just replaced all the '_Table.pm' modules for all the views by the
> modules generated with the Oracle schema. [Though this is not the correct
> way, I will have to resort to it for the time being at least. So, rather
> than building each time, I would just zip the gus-application whereever I
> need to run it with the postgresql version].
>
>
Thanks for all your work-- it's very helpful to us and everyone working
on the Postgres stuff. We'll need to all work together to ensure that
the plugins are cross platform, and in cases like the date issue, we'll
likely need to provide some logic so that they behave properly
regardless of the underlying RDBMS. Do you have a developer account on
the GUS CVS?
> Please let me know your suggestions, comments about the same.
>
>
> Thanks a lot,
> Jeetendra.
>
>
>
>
>
>
>>Hi Alberto,
>>
>>I don't expect to release any new Postgres work until after the first of
>>the year. The largest issue at this point is how to address subclassing
>>in GUS and the implementation tables. It's not specific to Postgres--
>>it's an open area of discussion here at CBIL.
>>
>>Continue to follow the GUSDEV list for releases and announcements, and
>>thanks for the interest.
>>
>>--Mike
>>
>>
>>Alberto Davila wrote:
>>
>>>Hi Michael, Jeetendra,
>>>
>>>Recently one of our students (Pablo Mendes) posted a error log in gusdev
>>>regarding the PostgreSQL version of GUS, but no luck to get any reply
>>>:-(
>>>
>>>I wonder to know any of you would have plans to release a new version of
>>>the PosgreSQL GUS, then we can track it and finish our installation...
>>>hopefully, this postgreSQL version can help GUS to become more popular,
>>>then attract more programmers to help with the development/improvement
>>>of it,
>>>
>>>Thanks, Alberto
>>>
>>>
>>>
>>>
>>>
>>>Jeetendra Soneja wrote:
>>>
>>>
>>>>Hi Michael,
>>>>
>>>>Thanks for your reply. I had another problem running the plugins using
>>>>the
>>>>Postgresql version. I have generated all the objects by following the
>>>>normal build procedure. However, I am getting the following error while
>>>>running the plugin:
>>>>
>>>>Error: attempting to access a child 'GUS::Model::DoTS::NAEntry' of
>>>>table
>>>>'GUS::Model::DoTS::ExternalNASequence' , but that table does not have a
>>>>child of that type. at
>>>>/home/soneja.local/gusHomePG/lib/perl/GUS/Model/GusRow.pm line 396,
>>>><GEN0>
>>>>line 163.
>>>>
>>>>When I opened the automatically generated ExternalNASequence_Table.pm,
>>>>it's child list is empty.
>>>>
>>>>Did I miss something during the build process ?
>>>>
>>>>Thank you for your help.
>>>>
>>>>Jeetendra.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Jeetendra:
>>>>>
>>>>>Jeetendra Soneja wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi Michael,
>>>>>>
>>>>>> Thanks for the updates. After downloading the latest code from the
>>>>>>CVS,
>>>>>>I was able to register a couple of plugins successfully. Just a small
>>>>>>change while registering GBParser, I had to comment out 'use
>>>>>>GUS::Model::DoTS::NAFeatureImp' line.
>>>>>>
>>>>>>
>>>>>
>>>>>Right, and further, while this technically works in Oracle, it
>>>>>represents an incorrect usage of the data model: The IMP tables
>>>>>should
>>>>>NEVER be used, either directly in SQL queries, nor through the object
>>>>>layer. Instead, the appropriate superclass should be used
>>>>>(GUS::Model::DoTS::NAFeature in this case)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I am trying to run GBParser and am having the following problems :-
>>>>>>
>>>>>>--An oracle-specific call setOracleDateFormat() in the run mode of
>>>>>>the
>>>>>>plugin was causing problems. (For the time being I have commented it)
>>>>>>
>>>>>>
>>>>>
>>>>>In addition, it looks like GBParser uses Oracle's sysdate in setting
>>>>>the
>>>>>release date.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>--It's having problems inserting rows into the tables. The value ''
>>>>>>is
>>>>>>being inserted into the NUMERIC type columns. Postgresql doesn't
>>>>>>seem to
>>>>>>interprete this as a null value, but an emptry string.
>>>>>>
>>>>>>
>>>>>
>>>>>Thanks--- This will need to be resolved higher up in the object layer.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Thank you once again for your help.
>>>>>>
>>>>>>
>>>>>
>>>>>Thank you for all your testing!! I have a growing list of issues and
>>>>>fixes for the Postgres version-- I'll keep this list updated as fixes
>>>>>are committed to CVS, and please continue to mail the list with your
>>>>>progress in getting this stuff working.
>>>>>
>>>>>--Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Jeetendra.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>All,
>>>>>>>
>>>>>>>I've updated DbiDbHandle in CVS to address the capitalization issue
>>>>>>>(thanks to Angel for the pointer here).
>>>>>>>
>>>>>>>This should then allow plugins to be registered with postgres GUS
>>>>>>>schemas.
>>>>>>>
>>>>>>>Just to recap:
>>>>>>>
>>>>>>>1) You'll need to use the latest SQL scripts sent by me on 11/30,
>>>>>>>and
>>>>>>>the latest CVS (as of now!)
>>>>>>>2) You'll need to change line 34 of GusApplication such that the
>>>>>>>requiredDbVersion for Core is 3.0, not 3.
>>>>>>>3) You'll need to manually add rows as outlined in VBI's GUS
>>>>>>>installation document. In addition, you'll need to add these rows:
>>>>>>>
>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>VALUES(0,'string',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>VALUES(1,'float',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>VALUES(2,'int',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>VALUES(3,'ref',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>VALUES(4,'boolean',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>INSERT INTO Core.AlgorithmParamKeyType
>>>>>>>VALUES(5,'date',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>>
>>>>>>>Thanks,
>>>>>>>
>>>>>>>Mike
>>>>>>>
>>>>>>>
>>>>>>>Jeetendra Soneja wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi all,
>>>>>>>>
>>>>>>>>The reason that I got errors that I posted earlier was that I did
>>>>>>>>not
>>>>>>>>do
>>>>>>>>a
>>>>>>>>build. I had just created the Postgresql GUS schema and was trying
>>>>>>>>to
>>>>>>>>register the gus application. However, after doing a build, things
>>>>>>>>worked
>>>>>>>>out fine.
>>>>>>>>
>>>>>>>>I would like to list some of the problems that I have faced till
>>>>>>>>this
>>>>>>>>point in using the Postgresql version:-
>>>>>>>>
>>>>>>>>-- The rows included in the script gus-rows.pl need a minor
>>>>>>>>modification.
>>>>>>>>Values in the rows that are being inserted into core.databaseinfo
>>>>>>>>need
>>>>>>>>to
>>>>>>>>be changed. The names of the schemas CORE, DOTS and SRES should be
>>>>>>>>changed
>>>>>>>>Core, DoTS, SRes respectively. Also the values for the version
>>>>>>>>numbers
>>>>>>>>should be changed from 1.0 and 3.0 to 1 and 3 respectively.
>>>>>>>>
>>>>>>>>-- Currently, I am having trouble registering a plugin (any
>>>>>>>>plugin). A
>>>>>>>>number of modules/subroutines are retrieving row as a
>>>>>>>>hash-reference
>>>>>>>>and
>>>>>>>>access a value in a row using key, i.e. column name of the table.
>>>>>>>>And
>>>>>>>>all
>>>>>>>>the keys used in the code are in upper case. This works in case of
>>>>>>>>oracle,
>>>>>>>>however, select statements in Postgresql return all the column
>>>>>>>>names in
>>>>>>>>lower case. Therefore, in this case, it couldn't find the row for
>>>>>>>>ga in
>>>>>>>>the core.algorithmimplementation table (although it's there since I
>>>>>>>>have
>>>>>>>>already registered ga). And when I change the key/column name to
>>>>>>>>lower
>>>>>>>>case in GusApplication.pm code, it worked fine.
>>>>>>>>
>>>>>>>>I would appreciate any suggestion or comments.
>>>>>>>>
>>>>>>>>Thanks a lot,
>>>>>>>>Jeetendra.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Hi Jeetendra,
>>>>>>>>>
>>>>>>>>>Comments below....
>>>>>>>>>
>>>>>>>>>Jeetendra Soneja wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Hi Michael,
>>>>>>>>>> I am glad that the PostgreSQL version has been released.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>This is not an official release!! These are preliminary scripts,
>>>>>>>>>which
>>>>>>>>>have had very little testing and are likely to change in the
>>>>>>>>>future
>>>>>>>>>(although probably not significantly).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I had a question about using it. Could you tell me if any of
>>>>>>>>>>the
>>>>>>>>>>existing plugins (especially those in Common::Plugin) would work
>>>>>>>>>>with PostgreSQL version of GUS ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>No existing plugins have been tested with PGGUS. Please report
>>>>>>>>>any
>>>>>>>>>successes or failures you have to the list.
>>>>>>>>>
>>>>>>>>>--Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Thanks,
>>>>>>>>>>Jeetendra.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>All,
>>>>>>>>>>>
>>>>>>>>>>>Postgres GUS scripts are attached. The first, pggus.sql
>>>>>>>>>>>contains
>>>>>>>>>>>DDL
>>>>>>>>>>>for creating GUS tables, indexes, constraints, and sequences.
>>>>>>>>>>>The
>>>>>>>>>>>second, gus-rows.sql, contains DML for populating the
>>>>>>>>>>>core.tableinfo
>>>>>>>>>>>and
>>>>>>>>>>>core.databaseinfo tables.
>>>>>>>>>>>
>>>>>>>>>>>Consider these early beta-- this is not part of an official
>>>>>>>>>>>release,
>>>>>>>>>>>they've had very limited testing, and they are unsupported. In
>>>>>>>>>>>general
>>>>>>>>>>>the existing documentation should provide the information
>>>>>>>>>>>needed to
>>>>>>>>>>>create an instance with these and GUS with it, but there are
>>>>>>>>>>>derivations
>>>>>>>>>>>that will be necessary.
>>>>>>>>>>>
>>>>>>>>>>>More information on Postgres and GUS, including an official
>>>>>>>>>>>release,
>>>>>>>>>>>should be coming in the next several weeks.
>>>>>>>>>>>
>>>>>>>>>>>Thanks,
>>>>>>>>>>>
>>>>>>>>>>>Mike
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>-------------------
>>
>>------------------------------------
>>
>>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>>>users.
>>>>>>>Discover which products truly live up to the hype. Start reading
>>>>>>>now.
>>>>>>>http://productguide.itmanagersjournal.com/
>>>>>>>_______________________________________________
>>>>>>>Gusdev-gusdev mailing list
>>>>>>>Gus...@li...
>>>>>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>-------------------------------------------------------
>>>>>SF email is sponsored by - The IT Product Guide
>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>users.
>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>http://productguide.itmanagersjournal.com/
>>>>>_______________________________________________
>>>>>Gusdev-gusdev mailing list
>>>>>Gus...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
|
|
From: Chris S. <sto...@pc...> - 2004-12-22 21:35:36
|
Yes, I see the same problem and will have someone look into it (hopefully sooner than after the holiday break!). Chris On Dec 22, 2004, at 2:55 PM, Sucheta Tripathy wrote: > I am sorry for this kind off the track question . I was trying to look > into RAD3.assay, RAD3.quantification through the schema browser, but > could not open it. > > Is there a problem? or my computer has it? > > Thanks > > Sucheta > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
|
From: Elisabetta M. <man...@pc...> - 2004-12-22 21:16:52
|
We have had some db upgrades that might have affected this. The people that can help with this are currently on vacation, so I imagine they will address it after the holiday break. Sorry for the inconvenience, Elisabetta --- On Wed, 22 Dec 2004, Sucheta Tripathy wrote: > I am sorry for this kind off the track question . I was trying to look into > RAD3.assay, RAD3.quantification through the schema browser, but could not > open it. > > Is there a problem? or my computer has it? > > Thanks > > Sucheta > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > |
|
From: Sucheta T. <su...@vb...> - 2004-12-22 19:56:08
|
I am sorry for this kind off the track question . I was trying to look into RAD3.assay, RAD3.quantification through the schema browser, but could not open it. Is there a problem? or my computer has it? Thanks Sucheta |
|
From: Jeetendra S. <so...@vb...> - 2004-12-20 15:40:42
|
Hi Michael,
I somehow managed to get a Postgresql version of GUS working,
however, this schema is the mirror of the current Oracle GUS schema
and not the scripts that were mailed to the list. The project that I
am working on requires us to have Postgresql as the backend, and I
really wanted something working for the time being. Therefore, I
tried to modify a number of things with the Postgresql scripts that
you had sent on the list. However, I faced some major issues such as,
the inherited tables did not have the primary key contraint defined
even though the base table has it. Similarly, they do not inherit the
children associated with the base table via foreign key relationship.
Even after defining the primary keys and the child relationships for
all the inherited tables, it didn't work. I would like to
point one more thing here. If we insert a row into the inherited table,
although this row does appear in the base table too, this row neither
obeys the foreign key contraint nor the primary key constraint that is
defined on the base table.
So, finally I generated the Postgresql version of the existing Oracle
schema that has views defined on the implementation tables. After
this, I generated insert, update and delete rules for all the views.
After some modifications to plugins, I have it finally working with
the existing gus application. However, I have tested it only with
SubmitRow, GBParser, LoadTaxon and LoadBlastSimFast plugins since these
are the ones that I will be using the most.
Here is the list of issues that I faced while getting the plugins run with
Postgresql schema :-
--I changed the date field from 'sysdate' to 'now()' in LoadBlastSimFast.pm
--In GBParser.pm I changed the following line from
$release_date = sysdate;
to
$release_date = $externalDatabaseRow->getDatabase()->getDateFunction();
--Inserted the following lines since in Genbank format, BASE COUNT line is
not mandatory and if this line is not present, it gives error on trying to
insert emptry string for numeric datatype.
$h->{'a_count'} = "null" if(!$h->{'a_count'});
$h->{'c_count'} = "null" if(!$h->{'c_count'});
$h->{'g_count'} = "null" if(!$h->{'g_count'});
$h->{'t_count'} = "null" if(!$h->{'t_count'});
--Changed the columns names left to leftcol and right to rightcol for the
view RAD3.Scan (and its version table too).
--The most significant problem that I faced was with the view columns that
are NOT nullable. Is postgresql, even if the actual table has a particular
column as NOT NULLABLE, this information is not present in the view
description (or its metadata). Therefore, the ViewName_Table.pm modules
generated for the views have all the columns as NULLABLE. Therefore, I
have just replaced all the '_Table.pm' modules for all the views by the
modules generated with the Oracle schema. [Though this is not the correct
way, I will have to resort to it for the time being at least. So, rather
than building each time, I would just zip the gus-application whereever I
need to run it with the postgresql version].
Please let me know your suggestions, comments about the same.
Thanks a lot,
Jeetendra.
>
> Hi Alberto,
>
> I don't expect to release any new Postgres work until after the first of
> the year. The largest issue at this point is how to address subclassing
> in GUS and the implementation tables. It's not specific to Postgres--
> it's an open area of discussion here at CBIL.
>
> Continue to follow the GUSDEV list for releases and announcements, and
> thanks for the interest.
>
> --Mike
>
>
> Alberto Davila wrote:
>> Hi Michael, Jeetendra,
>>
>> Recently one of our students (Pablo Mendes) posted a error log in gusdev
>> regarding the PostgreSQL version of GUS, but no luck to get any reply
>> :-(
>>
>> I wonder to know any of you would have plans to release a new version of
>> the PosgreSQL GUS, then we can track it and finish our installation...
>> hopefully, this postgreSQL version can help GUS to become more popular,
>> then attract more programmers to help with the development/improvement
>> of it,
>>
>> Thanks, Alberto
>>
>>
>>
>>
>>
>> Jeetendra Soneja wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your reply. I had another problem running the plugins using
>>> the
>>> Postgresql version. I have generated all the objects by following the
>>> normal build procedure. However, I am getting the following error while
>>> running the plugin:
>>>
>>> Error: attempting to access a child 'GUS::Model::DoTS::NAEntry' of
>>> table
>>> 'GUS::Model::DoTS::ExternalNASequence' , but that table does not have a
>>> child of that type. at
>>> /home/soneja.local/gusHomePG/lib/perl/GUS/Model/GusRow.pm line 396,
>>> <GEN0>
>>> line 163.
>>>
>>> When I opened the automatically generated ExternalNASequence_Table.pm,
>>> it's child list is empty.
>>>
>>> Did I miss something during the build process ?
>>>
>>> Thank you for your help.
>>>
>>> Jeetendra.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Hi Jeetendra:
>>>>
>>>> Jeetendra Soneja wrote:
>>>>
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Thanks for the updates. After downloading the latest code from the
>>>>> CVS,
>>>>> I was able to register a couple of plugins successfully. Just a small
>>>>> change while registering GBParser, I had to comment out 'use
>>>>> GUS::Model::DoTS::NAFeatureImp' line.
>>>>>
>>>>>
>>>>
>>>> Right, and further, while this technically works in Oracle, it
>>>> represents an incorrect usage of the data model: The IMP tables
>>>> should
>>>> NEVER be used, either directly in SQL queries, nor through the object
>>>> layer. Instead, the appropriate superclass should be used
>>>> (GUS::Model::DoTS::NAFeature in this case)
>>>>
>>>>
>>>>
>>>>> I am trying to run GBParser and am having the following problems :-
>>>>>
>>>>> --An oracle-specific call setOracleDateFormat() in the run mode of
>>>>> the
>>>>> plugin was causing problems. (For the time being I have commented it)
>>>>>
>>>>>
>>>>
>>>> In addition, it looks like GBParser uses Oracle's sysdate in setting
>>>> the
>>>> release date.
>>>>
>>>>
>>>>
>>>>> --It's having problems inserting rows into the tables. The value ''
>>>>> is
>>>>> being inserted into the NUMERIC type columns. Postgresql doesn't
>>>>> seem to
>>>>> interprete this as a null value, but an emptry string.
>>>>>
>>>>>
>>>>
>>>> Thanks--- This will need to be resolved higher up in the object layer.
>>>>
>>>>
>>>>
>>>>> Thank you once again for your help.
>>>>>
>>>>>
>>>>
>>>> Thank you for all your testing!! I have a growing list of issues and
>>>> fixes for the Postgres version-- I'll keep this list updated as fixes
>>>> are committed to CVS, and please continue to mail the list with your
>>>> progress in getting this stuff working.
>>>>
>>>> --Mike
>>>>
>>>>
>>>>
>>>>> Jeetendra.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> All,
>>>>>>
>>>>>> I've updated DbiDbHandle in CVS to address the capitalization issue
>>>>>> (thanks to Angel for the pointer here).
>>>>>>
>>>>>> This should then allow plugins to be registered with postgres GUS
>>>>>> schemas.
>>>>>>
>>>>>> Just to recap:
>>>>>>
>>>>>> 1) You'll need to use the latest SQL scripts sent by me on 11/30,
>>>>>> and
>>>>>> the latest CVS (as of now!)
>>>>>> 2) You'll need to change line 34 of GusApplication such that the
>>>>>> requiredDbVersion for Core is 3.0, not 3.
>>>>>> 3) You'll need to manually add rows as outlined in VBI's GUS
>>>>>> installation document. In addition, you'll need to add these rows:
>>>>>>
>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>> VALUES(0,'string',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>> VALUES(1,'float',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>> VALUES(2,'int',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>> VALUES(3,'ref',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>> VALUES(4,'boolean',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>> INSERT INTO Core.AlgorithmParamKeyType
>>>>>> VALUES(5,'date',now(),1,1,1,1,1,0,1, 1, 1, 1);
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> Jeetendra Soneja wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> The reason that I got errors that I posted earlier was that I did
>>>>>>> not
>>>>>>> do
>>>>>>> a
>>>>>>> build. I had just created the Postgresql GUS schema and was trying
>>>>>>> to
>>>>>>> register the gus application. However, after doing a build, things
>>>>>>> worked
>>>>>>> out fine.
>>>>>>>
>>>>>>> I would like to list some of the problems that I have faced till
>>>>>>> this
>>>>>>> point in using the Postgresql version:-
>>>>>>>
>>>>>>> -- The rows included in the script gus-rows.pl need a minor
>>>>>>> modification.
>>>>>>> Values in the rows that are being inserted into core.databaseinfo
>>>>>>> need
>>>>>>> to
>>>>>>> be changed. The names of the schemas CORE, DOTS and SRES should be
>>>>>>> changed
>>>>>>> Core, DoTS, SRes respectively. Also the values for the version
>>>>>>> numbers
>>>>>>> should be changed from 1.0 and 3.0 to 1 and 3 respectively.
>>>>>>>
>>>>>>> -- Currently, I am having trouble registering a plugin (any
>>>>>>> plugin). A
>>>>>>> number of modules/subroutines are retrieving row as a
>>>>>>> hash-reference
>>>>>>> and
>>>>>>> access a value in a row using key, i.e. column name of the table.
>>>>>>> And
>>>>>>> all
>>>>>>> the keys used in the code are in upper case. This works in case of
>>>>>>> oracle,
>>>>>>> however, select statements in Postgresql return all the column
>>>>>>> names in
>>>>>>> lower case. Therefore, in this case, it couldn't find the row for
>>>>>>> ga in
>>>>>>> the core.algorithmimplementation table (although it's there since I
>>>>>>> have
>>>>>>> already registered ga). And when I change the key/column name to
>>>>>>> lower
>>>>>>> case in GusApplication.pm code, it worked fine.
>>>>>>>
>>>>>>> I would appreciate any suggestion or comments.
>>>>>>>
>>>>>>> Thanks a lot,
>>>>>>> Jeetendra.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Jeetendra,
>>>>>>>>
>>>>>>>> Comments below....
>>>>>>>>
>>>>>>>> Jeetendra Soneja wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Michael,
>>>>>>>>> I am glad that the PostgreSQL version has been released.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is not an official release!! These are preliminary scripts,
>>>>>>>> which
>>>>>>>> have had very little testing and are likely to change in the
>>>>>>>> future
>>>>>>>> (although probably not significantly).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I had a question about using it. Could you tell me if any of
>>>>>>>>> the
>>>>>>>>> existing plugins (especially those in Common::Plugin) would work
>>>>>>>>> with PostgreSQL version of GUS ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> No existing plugins have been tested with PGGUS. Please report
>>>>>>>> any
>>>>>>>> successes or failures you have to the list.
>>>>>>>>
>>>>>>>> --Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jeetendra.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> All,
>>>>>>>>>>
>>>>>>>>>> Postgres GUS scripts are attached. The first, pggus.sql
>>>>>>>>>> contains
>>>>>>>>>> DDL
>>>>>>>>>> for creating GUS tables, indexes, constraints, and sequences.
>>>>>>>>>> The
>>>>>>>>>> second, gus-rows.sql, contains DML for populating the
>>>>>>>>>> core.tableinfo
>>>>>>>>>> and
>>>>>>>>>> core.databaseinfo tables.
>>>>>>>>>>
>>>>>>>>>> Consider these early beta-- this is not part of an official
>>>>>>>>>> release,
>>>>>>>>>> they've had very limited testing, and they are unsupported. In
>>>>>>>>>> general
>>>>>>>>>> the existing documentation should provide the information
>>>>>>>>>> needed to
>>>>>>>>>> create an instance with these and GUS with it, but there are
>>>>>>>>>> derivations
>>>>>>>>>> that will be necessary.
>>>>>>>>>>
>>>>>>>>>> More information on Postgres and GUS, including an official
>>>>>>>>>> release,
>>>>>>>>>> should be coming in the next several weeks.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> -------------------
> ------------------------------------
>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>> Read honest & candid reviews on hundreds of IT Products from real
>>>>>> users.
>>>>>> Discover which products truly live up to the hype. Start reading
>>>>>> now.
>>>>>> http://productguide.itmanagersjournal.com/
>>>>>> _______________________________________________
>>>>>> Gusdev-gusdev mailing list
>>>>>> Gus...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading now.
>>>> http://productguide.itmanagersjournal.com/
>>>> _______________________________________________
>>>> Gusdev-gusdev mailing list
>>>> Gus...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
--
Jeetendra Soneja
Research Associate
Virginia Bioinformatics Institute
1880 Pratt Dr., Building XV
Blacksburg, VA 24060, USA
Phone: (540)-231-2789
http://www.vbi.vt.edu
|
|
From: marc j. <de...@ho...> - 2004-12-17 18:21:11
|
That wasn't it, but things are resolved. For now. :) Thanks for your help! Regards, Marc >From: Steve Fischer <sfi...@pc...> >To: marc jackson <de...@ho...> >CC: gus...@li... >Subject: Re: [Gusdev-gusdev] problems building gus on redhat linux >Date: Fri, 17 Dec 2004 07:36:37 -0500 > >Marc- > >i suspect that you haven't defined the environment variable >$GUS_CONFIG_FILE. > >it should be discussed in the docs. > >steve > >[sfischer@cottus ~]$ echo $GUS_CONFIG_FILE >/home/sfischer/.gus.properties >[sfischer@cottus ~]$ more $GUS_CONFIG_FILE >databaseLogin=your_login >databasePassword=your_password > >readOnlyDatabaseLogin=your_login >readOnlyDatabasePassword=your_password > >dbiDsn=dbi:Oracle:host=cbilbld.pcbi.upenn.edu;sid=cbilbld #your >dsn string here > >coreSchemaName=Core >userName=sfischer #your user name here >group=CBIL # your group name here >project=GUS # your project here >[sfischer@cottus ~]$ > > > >marc jackson wrote: > >>Hello, >> I'm having a problem getting GUS to install/compile. I've been >>able to configure the database, but when I go to run the "ga" >>command to bootstrap in data. it pukes. In working with Ed >>Robinson, we got to the 2nd build. Specifically: >> build GUS install -append returns the following error: >> [exec] Required property 'group' must be specified in at >>/opt/gus/gus_home/lib/perl/CBIL/Util/PropertySet.pm line 53. >>BUILD FAILED >>/opt/gus/project_home/install/build.xml:26: The following error >>occurred while executing this line: >>/opt/gus/project_home/GUS/build.xml:190: exec returned: -1 >> any help would be appreacited. >> Regards, >> Marc >>------------------------------------------------------- SF email is >>sponsored by - The IT Product Guide Read honest & candid reviews on >>hundreds of IT Products from real users. Discover which products >>truly live up to the hype. Start reading now. >>http://productguide.itmanagersjournal.com/ >>_______________________________________________ Gusdev-gusdev >>mailing list Gus...@li... >>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > |
|
From: Steve F. <sfi...@pc...> - 2004-12-17 12:35:24
|
Marc- i suspect that you haven't defined the environment variable $GUS_CONFIG_FILE. it should be discussed in the docs. steve [sfischer@cottus ~]$ echo $GUS_CONFIG_FILE /home/sfischer/.gus.properties [sfischer@cottus ~]$ more $GUS_CONFIG_FILE databaseLogin=your_login databasePassword=your_password readOnlyDatabaseLogin=your_login readOnlyDatabasePassword=your_password dbiDsn=dbi:Oracle:host=cbilbld.pcbi.upenn.edu;sid=cbilbld #your dsn string here coreSchemaName=Core userName=sfischer #your user name here group=CBIL # your group name here project=GUS # your project here [sfischer@cottus ~]$ marc jackson wrote: > Hello, > > I'm having a problem getting GUS to install/compile. I've been able to > configure the database, but when I go to run the "ga" command to > bootstrap in data. it pukes. In working with Ed Robinson, we got to > the 2nd build. Specifically: > > build GUS install -append returns the following error: > > [exec] Required property 'group' must be specified in at > /opt/gus/gus_home/lib/perl/CBIL/Util/PropertySet.pm line 53. > BUILD FAILED > /opt/gus/project_home/install/build.xml:26: The following error > occurred while executing this line: > /opt/gus/project_home/GUS/build.xml:190: exec returned: -1 > > any help would be appreacited. > > Regards, > > Marc > ------------------------------------------------------- SF email is > sponsored by - The IT Product Guide Read honest & candid reviews on > hundreds of IT Products from real users. Discover which products truly > live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ Gusdev-gusdev mailing > list Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
|
From: marc j. <de...@ho...> - 2004-12-16 20:57:16
|
<html><div style='background-color:'><DIV class=RTE>Hello,</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>I'm having a problem getting GUS to install/compile. I've been able to configure the database, but when I go to run the "ga" command to bootstrap in data. it pukes. In working with Ed Robinson, we got to the 2nd build. Specifically:</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>build GUS install -append returns the following error:</DIV> <DIV class=RTE> </DIV> <DIV class=RTE> [exec] Required property 'group' must be specified in at /opt/gus/gus_home/lib/perl/CBIL/Util/PropertySet.pm line 53.</DIV> <DIV class=RTE>BUILD FAILED<BR>/opt/gus/project_home/install/build.xml:26: The following error occurred while executing this line:<BR>/opt/gus/project_home/GUS/build.xml:190: exec returned: -1</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>any help would be appreacited.</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>Regards,</DIV> <DIV class=RTE> </DIV> <DIV class=RTE>Marc<BR></DIV></div></html> |
|
From: Steve F. <sfi...@pc...> - 2004-12-13 14:45:52
|
folks- i took a look at Ed's dump of the bioperl objects created by the parse of genbank. for genbank, the bioperl Annotation objects are only used to describe the sequence and not any individual features. our mapping assumes that, so we're lucky so far. we'll need to have a look at tigr. nonetheless, i think we need to adjust our mapping XML schema a tad. the main insight is that the source of our mapping is not genbank, or tiger, etc, but... bioperl objects. our mapping syntax must describe how to map bioperl feature objects into gus, regardless of the origin of the data. and, bioperl features have 'tags' and 'annotation' right now we have a <qualifier> tag that was intended to map an input qualifier to a gus attribute. but, bioperl doesn't have 'qualifiers' so, i think we need to replace <qualifer> with: <tag> so far, we don't need <annotation> for the feature mapping, and lets hope we don't. but, if we do, at least our xml will be forward compatible. that said, we still owe ourselves a mapping for the tags and annotation that directly describe the sequence. steve Steve Fischer wrote: > paul- see in line > > steve > > Paul Mooney wrote: > >> >> On 10 Dec 2004, at 12:52, Steve Fischer wrote: >> >>> paul- >>> >>> ok, i see. >>> >>> are there any other examples besides curation in which you have >>> placed structured data in qualifiers? are there examples of >>> standard embl qualifiers in which you expect to find structured data >>> and parse it? >>> >> >> After talking with Arnaud it seems we can take each >> qualifier/structured field and create a new feature, with each one of >> its qualifiers holding one piece of data. This would fit into your >> mapping scheme. >> > ok. great. i was wondering about that. > > so does that mean that we can expect that no qualifiers will contain > structured data that needs to be parsed? > >>> in the case of curation, where do you put that info in GUS? >> >> >> >> It will probably end up as a note, for now at least. >> >>> >>> about systematic_ids, i understand what you've said. one thing >>> though. how do they relate to gene names? >> >> >> > ok, but, what i'm driving at is that the unflattener uses gene name > (/gene=) to decide what features go together in one gene model. > really, it wouldn't matter what the value of the /gene= is, as long as > it is identical for all features that belong to the gene. is that > consistent with your use of /gene? > >> They are the gene names :) >> Standard EMBL uses a /gene qualifier for the gene symbol and >> /standard_name for the human readable name. >> During sequencing and annotation using a single /gene conveys no >> meaning as to how stable/temporary the ID is. >> >>> steve >>> >>> Paul Mooney wrote: >>> >>>> >>>> On 9 Dec 2004, at 23:21, Steve Fischer wrote: >>>> >>>>> paul- >>>>> >>>>> let me start digesting this by email. >>>>> >>>>> about your extensions to EMBL. the bioPerl model we are parsing >>>>> into is based on generic features, tags and annotation. as long >>>>> as the extensions can be parsed into those objects we're half way >>>>> there. are the extensions syntactically consistent w/ standard >>>>> embl files, but varying only in the particulars of what the data >>>>> is called? >>>> >>>> >>>> >>>> >>>> We have additional qualifiers with values. The values hold >>>> structured information (say key=value pairs). >>>> Bioperl will quite happily parse them into tags and values. >>>> What controls the mapping of a tag to a GUS objects(s)? >>>> What parses the structured information out to populate the >>>> object(s) and fill in the objects fields (which is another mapping)? >>>> >>>> Something like this non-EMBL standard entry, curation, has several >>>> values in a fixed field format; >>>> >>>> /curation="name; origin; date; permission; type; dbref; notes ..." >>>> i.e. >>>> /curation="Matt Berriman; genedb; 20020128; public; comment" >>>> >>>> How do we specify where to put this in GUS? It's very PSU specific. >>>> Perhaps some sort of hook with specifying some perl code elsewhere >>>> to handle it? >>>> We currently store GO annotation in EMBL like this; >>>> >>>> /GO="aspect=process; GOid=GO:0006810; term=transport; >>>> evidence=ISS; db_xref=GOC:unpublished; with=SPTR:Q9UQ36; >>>> date=20001122" >>>> >>>> as EMBL only has the format /db_xref="GO:00123" but I hope there is >>>> a GO flat file loader so we don't have to worry about this in the >>>> future. >>>> >>>>> about building the hierarchy. if you looked at the bioperl api >>>>> for the unflattener, you'd see that its unflattening uses gene >>>>> name as a clue to deciding what features go together in a >>>>> particular gene model. >>>>> >>>>> can gene name be relied upon to identify all the features that are >>>>> associated with this gene? >>>> >>>> >>>> >>>> >>>> You can switch to use any qualifier you like to identify groups, >>>> but you can only specify *one*. >>>> We can have 2 :) >>>> In the same sequence a gene may be identified by systematic_id. >>>> Another gene in the same sequence maybe identified by >>>> temporary_systematic_id. >>>> Eventually all genes will get a systematic_id but not straight away. >>>> >>>> In theory it should be easy to modify the flattener to use a 'best >>>> name first' policy. >>>> >>>> For TIGR XML you'd have PUB_LOCUS and LUCUS as the best names, in >>>> that order. Their too mix identifiers but since the XML already has >>>> a hierarchy you might get away with it???? >>>> >>>> >>>>> finally, about the GO stuff, yes, we can probably reuse your code. >>>>> >>>>> steve >>>>> >>>>> >>>>> Paul Mooney wrote: >>>>> >>>>>> >>>>>> On 9 Dec 2004, at 19:31, Steve Fischer wrote: >>>>>> >>>>>>> paul- >>>>>>> >>>>>>> hey. do you want to set up a time to chat so i can catch you up >>>>>>> on what we have in mind? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> At the moment I'm curious how much can be achieved via a generic >>>>>> plugin. I think the plugin will need plugin's to do specialised >>>>>> parts :) However I'd be glad to give my assistance to the effort. >>>>>> Below are my random thoughts I've just had on the matter; >>>>>> >>>>>> >>>>>> Here at the PSU we store an awful lot of info that can not be >>>>>> stored in a standard EMBL file, hence we have extended it to fit >>>>>> out own needs. As an example we use several name qualifiers for >>>>>> genes; >>>>>> >>>>>> . systematic_id - the name cast in stone >>>>>> . temporary_systematic_id - the name as it is currently known >>>>>> . previous_systematic_id - as it was known >>>>>> . gene - EMBL standard qualifier >>>>>> >>>>>> Hence just trying to unflatten the EMBL file is tricky because >>>>>> systematic and temporary_sysetmatic_ids are mixed in the same >>>>>> sequence, hence building the hierarchy would need specialised >>>>>> code. TIGR XML has the same issue though so maybe its not too >>>>>> specialised after all :/ (PUB_LOCUS and LOCUS has a direct >>>>>> mapping to systematic_id and temporary_systematic_id). >>>>>> >>>>>> Something like this entry; >>>>>> /curation="name; origin; date; permission; type; dbref; notes >>>>>> ..." >>>>>> i.e. >>>>>> /curation="Matt Berriman; genedb; 20020128; public; comment" >>>>>> is unique to the PSU and I'm not sure where it fits in GUS. >>>>>> >>>>>> However; >>>>>> >>>>>> I have code that creates GO entries - supply a high level >>>>>> function with all the standard GO fields and it creates the 5 >>>>>> rows (?) in the different tables as required. This is definitely >>>>>> something that can be shared across centres, perhaps in a code >>>>>> library. All your code has to do is parse out the GO fields from >>>>>> the data. No reason why it couldn't accept a GO Bioperl object (I >>>>>> presume one exists). >>>>>> >>>>>> Perhaps the parsing needs to a super class for each data source >>>>>> and then sub-classed by each centre? >>>>>> >>>>>> Ok, enough ramblings. Does any of this make sense? >>>>>> Paul. >>>>>> >>>>>>> steve >>>>>>> >>>>>>> Chris Stoeckert wrote: >>>>>>> >>>>>>>> Hi Steve, >>>>>>>> Thanks for putting this out on gusdev. Marie-Adele indicated >>>>>>>> that Paul Mooney was very interested in this and I will likely >>>>>>>> meet with him about this when I visit in January. Please >>>>>>>> include him in email correspondence when not addressed to the >>>>>>>> general gusdev list. >>>>>>>> Thanks, >>>>>>>> Chris >>>>>>>> >>>>>>>> On Dec 9, 2004, at 2:11 PM, Steve Fischer wrote: >>>>>>>> >>>>>>>>> folks- >>>>>>>>> >>>>>>>>> the UGA folks and CBIL folks have started collaborating on a >>>>>>>>> new plugin called LoadAnnotatedSeqs. It will use BioPerl to >>>>>>>>> parse the input data. >>>>>>>>> >>>>>>>>> We expect it to take annotated sequences (NA at first) in >>>>>>>>> genbank, tigr xml and embl formats (plus any others supported >>>>>>>>> by the bioPerl parser). >>>>>>>>> >>>>>>>>> It will take an XML file that describes the mapping from the >>>>>>>>> input features to GUS features, and SO features. >>>>>>>>> It will also hard code special cases to handle qualifer data >>>>>>>>> that is distributed to tables outside of the NAFeature tables. >>>>>>>>> >>>>>>>>> For our projects we will be developing a mapping that unifies >>>>>>>>> the semantics of the data we are getting from our different >>>>>>>>> sources and formats. >>>>>>>>> (we plan to work with the PSU folks to incorporate the >>>>>>>>> knowledge they have acquired in their work to make an EMBL >>>>>>>>> parser) >>>>>>>>> >>>>>>>>> ideas and suggestions are encouraged. >>>>>>>>> >>>>>>>>> steve >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------- >>>>>>>>> SF email is sponsored by - The IT Product Guide >>>>>>>>> Read honest & candid reviews on hundreds of IT Products from >>>>>>>>> real users. >>>>>>>>> Discover which products truly live up to the hype. Start >>>>>>>>> reading now. http://productguide.itmanagersjournal.com/ >>>>>>>>> _______________________________________________ >>>>>>>>> Gusdev-gusdev mailing list >>>>>>>>> Gus...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
|
From: <pa...@pa...> - 2004-12-10 18:19:56
|
Hello all,<br />we're doing a GUS-Postgres installation from scratch here=
.
We observed all those problems that have already shown in the list and
fixed them as suggested. We're now facing some problems when loading
bootstrap data.<br /><br />When running<br
/>GUS::Common::Plugin::UpdateGusFromXML <br /><br />we got:<br /><br
/>DBD::Pg::st execute failed: ERROR:=A0 Bad numeric input format '' at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line<br />(complete
dump below)<br /><br />If we change the table structure to accept
characters instead of numeric values, we get this error:<br /><br
/>DBD::Pg::st execute failed: ERROR:=A0 value too long for type character=
(1)
at /usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 147,
<GEN0> line <br />(complete dump below)<br /><br />Do you have any
thoughts on this?<br /><br />Any help would be much appreciated.<br /><br
/>Pablo N. Mendes<br />pab...@uf...<br />MSc candidate<br />Federa=
l
University of Rio de Janeiro<br /><br />##############################<br
/>[pablo@kineto1 Bootstrapping]$ ga GUS::Common::Plugin::UpdateGusFromXML
--commit --filename=3DDoTS.SequenceType.xml<br />DBD::Pg::st execute fail=
ed:
ERROR:=A0 Bad numeric input format '' at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 147.<br />=A0<=
br
/>=A0SQL ERROR!! involving<br />=A0 <br />=A0=A0=A0 INSERT INTO Core.Algo=
rithmParam
(=A0 algorithm_param_key_id, group_read, user_read, other_write, order_nu=
m,
modification_date, boolean_value, row_group_id, string_value, user_write,
is_default, group_write, other_read, algorithm_param_id, row_user_id,
row_project_id, row_alg_invocation_id, algorithm_invocation_id )<br />=A0=
=A0=A0
VALUES=A0=A0 (=A0 ?, ?, ?, ?, ?, now(), '', ?, '', ?, ?, ?, ?, ?, ?, ?, ?=
, ?
)<br />=A0Values: 27, 1, 1, 0, 0, 1, 1, 0, 1, 1, 82, 5, 1, 11, 11 at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 187<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=3DHASH(0x8b9b=
990)','\x{a}
SQL ERROR!! involving\x{a} \x{a}=A0=A0=A0 INSERT INTO Core.AlgorithmParam=
...')
called at /usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line
150<br />=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=3DHASH(0x8b=
9b990)','GUS::ObjRelP::DbiDbHandle::st=3DHASH(0x8d1a5a4)','ARRAY(0x8d1d5c=
4)','\x{a}=A0=A0=A0
INSERT INTO Core.AlgorithmParam (=A0 algorithm_param_key_i...') called at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681<br />=A0=A0=A0=A0=
=A0=A0=A0
GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::Core::AlgorithmParam=3D=
HASH(0x8d1d2e8)','HASH(0x8d1d378)')
called at /usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiRow::insert('GUS::Model::Core::AlgorithmParam=3DHASH(0x8=
d1d2e8)')
called at /usr/gus/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::Model::GusRow::submit('GUS::Model::Core::AlgorithmParam=3DHASH(0x8d1=
d2e8)')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
1014<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::openInvocation('GUS::PluginMgr::GusApplic=
ation=3DHASH(0x8594c18)','GUS::Common::Plugin::UpdateGusFromXML=3DHASH(0x=
85c9380)')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
448<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode_RunOrReport('GUS::PluginMgr::=
GusApplication=3DHASH(0x8594c18)','GUS::Common::Plugin::UpdateGusFromXML'=
,1)
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
383<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode_Run('GUS::PluginMgr::GusAppli=
cation=3DHASH(0x8594c18)','GUS::Common::Plugin::UpdateGusFromXML')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
289<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplicati=
on=3DHASH(0x8594c18)','GUS::Common::Plugin::UpdateGusFromXML')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
198<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplicati=
on=3DHASH(0x8594c18)','ARRAY(0x85a84f0)')
called at /usr/gus/gus_home/bin/ga line 11<br />Database handle destroyed
without explicit disconnect.<br /><br />##########################<br
/>[pablo@kineto1 Bootstrapping]$ ga GUS::Common::Plugin::UpdateGusFromXML
--commit --filename=3DDoTS.SequenceType.xml<br />Fri Dec 10 15:24:50
2004=A0=A0=A0=A0=A0=A0=A0 COMMIT=A0 ON<br />DBD::Pg::st execute failed: E=
RROR:=A0 value too
long for type character(1) at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 147,
<GEN0> line 9.<br />=A0<br />=A0SQL ERROR!! involving<br />=A0 <br =
/>=A0=A0=A0
INSERT INTO DoTS.SequenceType (=A0 group_read, sequence_type_id, user_rea=
d,
parent_sequence_type_id, other_write, modification_date, row_group_id,
user_write, hierarchy, group_write, other_read, name, description,
row_user_id, row_project_id, row_alg_invocation_id, nucleotide_type )<br
/>=A0=A0=A0 VALUES=A0=A0 (=A0 ?, ?, ?, ?, ?, now(), ?, ?, ?, ?, ?, ?, ?, =
?, ?, ?, ?
)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
<br />=A0Values: 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, DNA, DNA, unknown
strandedness, 5, 1, 12, DNA at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 187<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=3DHASH(0x9688=
990)','\x{a}
SQL ERROR!! involving\x{a} \x{a}=A0=A0=A0 INSERT INTO DoTS.SequenceType (=
...')
called at /usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line
150<br />=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=3DHASH(0x96=
88990)','GUS::ObjRelP::DbiDbHandle::st=3DHASH(0x98239f8)','ARRAY(0x983a4c=
4)','\x{a}=A0=A0=A0
INSERT INTO DoTS.SequenceType (=A0 group_read, sequence_ty...') called at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681<br />=A0=A0=A0=A0=
=A0=A0=A0
GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::DoTS::SequenceType=3D=
HASH(0x95261a8)','HASH(0x98361bc)')
called at /usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiRow::insert('GUS::Model::DoTS::SequenceType=3DHASH(0x952=
61a8)')
called at /usr/gus/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::Model::GusRow::submit('GUS::Model::DoTS::SequenceType=3DHASH(0x95261=
a8)','undef',1)
called at /usr/gus/gus_home/lib/perl/GUS/Common/Plugin/UpdateGusFromXML.p=
m
line 118<br />=A0=A0=A0=A0=A0=A0=A0
GUS::Common::Plugin::UpdateGusFromXML::process('GUS::Common::Plugin::Upda=
teGusFromXML=3DHASH(0x90b6380)','ARRAY(0x963c138)')
called at /usr/gus/gus_home/lib/perl/GUS/Common/Plugin/UpdateGusFromXML.p=
m
line 70=A0=A0=A0=A0=A0=A0=A0
GUS::Common::Plugin::UpdateGusFromXML::run('GUS::Common::Plugin::UpdateGu=
sFromXML=3DHASH(0x90b6380)','HASH(0x97cf774)')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
453<br />=A0=A0=A0=A0=A0=A0=A0 eval {...} called at
/usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 450<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode_RunOrReport('GUS::PluginMgr::=
GusApplication=3DHASH(0x9081c18)','GUS::Common::Plugin::UpdateGusFromXML'=
,1)
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
383<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode_Run('GUS::PluginMgr::GusAppli=
cation=3DHASH(0x9081c18)','GUS::Common::Plugin::UpdateGusFromXML')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
289<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplicati=
on=3DHASH(0x9081c18)','GUS::Common::Plugin::UpdateGusFromXML')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
198<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplicati=
on=3DHASH(0x9081c18)','ARRAY(0x90954f0)')
called at /usr/gus/gus_home/bin/ga line 11<br />[pablo@kineto1
Bootstrapping]$ ga GUS::Common::Plugin::UpdateGusFromXML --commit
--filename=3DDoTS.SequenceType.xml<br />Fri Dec 10 15:26:54 2004=A0=A0=A0=
=A0=A0=A0=A0
COMMIT=A0 ON<br />DBD::Pg::st execute failed: ERROR:=A0 value too long fo=
r
type character(1) at /usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.p=
m
line 147, <GEN0> line 9.<br />=A0<br />=A0SQL ERROR!! involving<br =
/>=A0
<br />=A0=A0=A0 INSERT INTO DoTS.SequenceType (=A0 group_read, sequence_t=
ype_id,
user_read, parent_sequence_type_id, other_write, modification_date,
row_group_id, user_write, hierarchy, group_write, other_read, name,
description, row_user_id, row_project_id, row_alg_invocation_id,
nucleotide_type )<br />=A0=A0=A0 VALUES=A0=A0 (=A0 ?, ?, ?, ?, ?, now(), =
?, ?, ?, ?,
?, ?, ?, ?, ?, ?, ?
)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
<br />=A0Values: 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, DNA, DNA, unknown
strandedness, 5, 1, 13, DNA at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 187<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=3DHASH(0x9094=
990)','\x{a}
SQL ERROR!! involving\x{a} \x{a}=A0=A0=A0 INSERT INTO DoTS.SequenceType (=
...')
called at /usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line
150<br />=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=3DHASH(0x90=
94990)','GUS::ObjRelP::DbiDbHandle::st=3DHASH(0x922f9f8)','ARRAY(0x92464c=
4)','\x{a}=A0=A0=A0
INSERT INTO DoTS.SequenceType (=A0 group_read, sequence_ty...') called at
/usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 681<br />=A0=A0=A0=A0=
=A0=A0=A0
GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::DoTS::SequenceType=3D=
HASH(0x8f321a8)','HASH(0x92421bc)')
called at /usr/gus/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 628<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::ObjRelP::DbiRow::insert('GUS::Model::DoTS::SequenceType=3DHASH(0x8f3=
21a8)')
called at /usr/gus/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::Model::GusRow::submit('GUS::Model::DoTS::SequenceType=3DHASH(0x8f321=
a8)','undef',1)
called at /usr/gus/gus_home/lib/perl/GUS/Common/Plugin/UpdateGusFromXML.p=
m
line 118<br />=A0=A0=A0=A0=A0=A0=A0
GUS::Common::Plugin::UpdateGusFromXML::process('GUS::Common::Plugin::Upda=
teGusFromXML=3DHASH(0x8ac2380)','ARRAY(0x9048138)')
called at /usr/gus/gus_home/lib/perl/GUS/Common/Plugin/UpdateGusFromXML.p=
m
line 70=A0=A0=A0=A0=A0=A0=A0
GUS::Common::Plugin::UpdateGusFromXML::run('GUS::Common::Plugin::UpdateGu=
sFromXML=3DHASH(0x8ac2380)','HASH(0x91db774)')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
453<br />=A0=A0=A0=A0=A0=A0=A0 eval {...} called at
/usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 450<br
/>=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode_RunOrReport('GUS::PluginMgr::=
GusApplication=3DHASH(0x8a8dc18)','GUS::Common::Plugin::UpdateGusFromXML'=
,1)
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
383<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode_Run('GUS::PluginMgr::GusAppli=
cation=3DHASH(0x8a8dc18)','GUS::Common::Plugin::UpdateGusFromXML')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
289<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplicati=
on=3DHASH(0x8a8dc18)','GUS::Common::Plugin::UpdateGusFromXML')
called at /usr/gus/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line
198<br />=A0=A0=A0=A0=A0=A0=A0
GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplicati=
on=3DHASH(0x8a8dc18)','ARRAY(0x8aa14f0)')
called at /usr/gus/gus_home/bin/ga line 11<br /><br />
|
|
From: Paul M. <pj...@sa...> - 2004-12-10 16:53:13
|
>>> are there any other examples besides curation in which you have >>> placed structured data in qualifiers? are there examples of >>> standard embl qualifiers in which you expect to find structured data >>> and parse it? >>> >> >> After talking with Arnaud it seems we can take each >> qualifier/structured field and create a new feature, with each one of >> its qualifiers holding one piece of data. This would fit into your >> mapping scheme. >> > ok. great. i was wondering about that. Arnaud had to point out the obvious to me :) > so does that mean that we can expect that no qualifiers will contain > structured data that needs to be parsed? We can make it so their is no structured data to be parsed (we'll leave it in but ignore it). >>> about systematic_ids, i understand what you've said. one thing >>> though. how do they relate to gene names? >> >> > ok, but, what i'm driving at is that the unflattener uses gene name > (/gene=) to decide what features go together in one gene model. > really, it wouldn't matter what the value of the /gene= is, as long as > it is identical for all features that belong to the gene. is that > consistent with your use of /gene? We don't use /gene until we submit to EMBL, when we convert /systematic_ids for /genes. All EMBL files parsed into GUS have the previously mentioned name qualifiers. Look at this extract of an EMBL file FT CDS 1..3 FT /systematic_id="name1" . . FT CDS 4..8 FT /temporary_systematic_id="name2" Hence I need to tell the flattener to look for systematic_id first, then temporary_systematic_id. It is important for us to use both. |
30 messages has been excluded from this view by a project administrator.
