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: Michael S. <msa...@pc...> - 2005-11-03 15:32:23
|
Hi Henrique,
It looks like your connection string (from your command line) is =20
incorrect. Try:
dbi:Pg:dbname=3Dgustest
--Mike
On Nov 3, 2005, at 10:26 AM, Henrique Juc=E1 wrote:
> Hi all,
>
> I am trying to load nr to GUS, without success.... here's my command
> line and the error output:
>
> [juca1@kineto3 perl]$ ga GUS::Supported::Plugin::LoadNRDB
> --externalDatabaseName 'GenBank' --externalDatabaseVersion 'unknown'
> --gitax /gus/GUS-Files/gi_taxid_prot.dmp --nrdbFile /gus/GUS-Files/nr
> --sourceDB '2:gb, 3:emb, 4:dbj, 5:pir, 6:prf, 7:sp, 8:pdb, 9:pat,
> 10:bbs, 11:gnl, ref:168, 12:genpept' --tempLogin 'xxxx' --tempPassword
> 'xxxxxx' --dbiStr 'dbi:Pg:host=3Dlocalhost.localdomain;sid=3Dgustest'
> --verbose --maketemp
>
> Thu Nov 3 13:18:51 2005 ARG algoinvo 1
> Thu Nov 3 13:18:51 2005 ARG comment
> Thu Nov 3 13:18:51 2005 ARG commit 0
> Thu Nov 3 13:18:51 2005 ARG dbiStr
> dbi:Pg:host=3Dlocalhost.localdomain;sid=3Dgustest
> Thu Nov 3 13:18:51 2005 ARG debug 0
> Thu Nov 3 13:18:51 2005 ARG delete 0
> Thu Nov 3 13:18:51 2005 ARG externalDatabaseName =20
> GenBank
> Thu Nov 3 13:18:51 2005 ARG externalDatabaseVersion =20
> unknown
> Thu Nov 3 13:18:51 2005 ARG gitax
> /gus/GUS-Files/gi_taxid_prot.dmpThu Nov 3 13:18:51 2005 ARG
> group
> Thu Nov 3 13:18:51 2005 ARG gusconfigfile /gus/GUS/=20
> gus.properties
> Thu Nov 3 13:18:51 2005 ARG help
> Thu Nov 3 13:18:51 2005 ARG helpHTML
> Thu Nov 3 13:18:51 2005 ARG makeTemp 1
> Thu Nov 3 13:18:51 2005 ARG nrdbFile /gus/GUS-=20
> Files/nr
> Thu Nov 3 13:18:51 2005 ARG plugin 0
> Thu Nov 3 13:18:51 2005 ARG project
> Thu Nov 3 13:18:51 2005 ARG restart
> Thu Nov 3 13:18:51 2005 ARG restartTempTable 0
> Thu Nov 3 13:18:51 2005 ARG sourceDB 2:gb, 3:emb,
> 4:dbj, 5:pir, 6:prf, 7:sp, 8:pdb, 9:pat, 10:bbs, 11:gnl, ref:168,
> 12:genpept
> Thu Nov 3 13:18:51 2005 ARG sqlVerbose 0
> Thu Nov 3 13:18:51 2005 ARG tempLogin juca
> Thu Nov 3 13:18:51 2005 ARG tempPassword saci10
> Thu Nov 3 13:18:51 2005 ARG testnumber1
> Thu Nov 3 13:18:51 2005 ARG testnumber2
> Thu Nov 3 13:18:51 2005 ARG user
> Thu Nov 3 13:18:51 2005 ARG verbose 1
> Thu Nov 3 13:18:51 2005 ARG veryVerbose 0
> Thu Nov 3 13:18:51 2005 AlgInvocationId 59
> Thu Nov 3 13:18:51 2005 COMMIT commit off
> Thu Nov 3 13:18:51 2005 There are 12 entries in the source
> database hashThu Nov 3 13:20:11 2005 There are 7251218 gi to
> taxon_id pairs
>
> DBI connect('host=3Dlocalhost.localdomain;sid=3Dgustest','juca',...)
> failed: invalid connection option "sid"
> at /gus/GUS/gus_home/lib/perl/GUS/Supported/Plugin/LoadNRDB.pm =20
> line 320
>
> ERROR:
> Can't call method "do" on an undefined value at
> /gus/GUS/gus_home/lib/perl/GUS/Supported/Plugin/LoadNRDB.pm line 323.
>
> STACK TRACE:
> at /gus/GUS/gus_home/lib/perl/GUS/Supported/Plugin/LoadNRDB.pm =20
> line 323
> GUS::Supported::Plugin::LoadNRDB::makeTempTable=20
> ('GUS::Supported::Plugin::LoadNRDB=3DHASH(0x99a1504)','HASH=20
> (0x9f517fc)','HASH(0x9a39270)')
> called at /gus/GUS/gus_home/lib/perl/GUS/Supported/Plugin/LoadNRDB.pm
> line 210
> GUS::Supported::Plugin::LoadNRDB::run=20
> ('GUS::Supported::Plugin::LoadNRDB=3DHASH(0x99a1504)','HASH(0xa13d12c)')=
> called at /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm
> line 520
> eval {...} called at
> /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 512
> GUS::PluginMgr::GusApplication::doMajorMode_RunOrReport=20
> ('GUS::PluginMgr::GusApplication=3DHASH=20
> (0x9980c18)','GUS::Supported::Plugin::LoadNRDB',1)
> called at /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm
> line 430
> GUS::PluginMgr::GusApplication::doMajorMode_Run=20
> ('GUS::PluginMgr::GusApplication=3DHASH=20
> (0x9980c18)','GUS::Supported::Plugin::LoadNRDB')
> called at /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm
> line 337
> GUS::PluginMgr::GusApplication::doMajorMode=20
> ('GUS::PluginMgr::GusApplication=3DHASH=20
> (0x9980c18)','GUS::Supported::Plugin::LoadNRDB')
> called at /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm
> line 246
> GUS::PluginMgr::GusApplication::parseAndRun=20
> ('GUS::PluginMgr::GusApplication=3DHASH(0x9980c18)','ARRAY(0x99946a8)')
> called at /gus/GUS/gus_home/bin/ga line 11
>
> That option 'sid' is listed on the help file, so why is that the =20
> error?
>
> Thanks for the attention,
>
>
>
> Henrique Cesar Lemos Juc=E1 - http://www.bioinformatica.ufsc.br
>
> "As soon as you concern yourself with the "good" and "bad" of your =20
> fellows,
> you create an opening in your heart for maliciousness to enter. =20
> Testing,
> competing with, and criticizing others weaken and defeat you."
>
> Morihei Ueshiba, O-Sensei (1883-1969)
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. =20=
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
|
|
From: <hen...@gm...> - 2005-11-03 15:26:53
|
Hi all,
I am trying to load nr to GUS, without success.... here's my command
line and the error output:
[juca1@kineto3 perl]$ ga GUS::Supported::Plugin::LoadNRDB
--externalDatabaseName 'GenBank' --externalDatabaseVersion 'unknown'
--gitax /gus/GUS-Files/gi_taxid_prot.dmp --nrdbFile /gus/GUS-Files/nr
--sourceDB '2:gb, 3:emb, 4:dbj, 5:pir, 6:prf, 7:sp, 8:pdb, 9:pat,
10:bbs, 11:gnl, ref:168, 12:genpept' --tempLogin 'xxxx' --tempPassword
'xxxxxx' --dbiStr 'dbi:Pg:host=3Dlocalhost.localdomain;sid=3Dgustest'
--verbose --maketemp
Thu Nov 3 13:18:51 2005 ARG algoinvo 1
Thu Nov 3 13:18:51 2005 ARG comment
Thu Nov 3 13:18:51 2005 ARG commit 0
Thu Nov 3 13:18:51 2005 ARG dbiStr=20
dbi:Pg:host=3Dlocalhost.localdomain;sid=3Dgustest
Thu Nov 3 13:18:51 2005 ARG debug 0
Thu Nov 3 13:18:51 2005 ARG delete 0
Thu Nov 3 13:18:51 2005 ARG externalDatabaseName GenBank
Thu Nov 3 13:18:51 2005 ARG externalDatabaseVersion unknown
Thu Nov 3 13:18:51 2005 ARG gitax =20
/gus/GUS-Files/gi_taxid_prot.dmpThu Nov 3 13:18:51 2005 ARG =20
group
Thu Nov 3 13:18:51 2005 ARG gusconfigfile /gus/GUS/gus.proper=
ties
Thu Nov 3 13:18:51 2005 ARG help
Thu Nov 3 13:18:51 2005 ARG helpHTML
Thu Nov 3 13:18:51 2005 ARG makeTemp 1
Thu Nov 3 13:18:51 2005 ARG nrdbFile /gus/GUS-Files/nr
Thu Nov 3 13:18:51 2005 ARG plugin 0
Thu Nov 3 13:18:51 2005 ARG project
Thu Nov 3 13:18:51 2005 ARG restart
Thu Nov 3 13:18:51 2005 ARG restartTempTable 0
Thu Nov 3 13:18:51 2005 ARG sourceDB 2:gb, 3:emb,
4:dbj, 5:pir, 6:prf, 7:sp, 8:pdb, 9:pat, 10:bbs, 11:gnl, ref:168,
12:genpept
Thu Nov 3 13:18:51 2005 ARG sqlVerbose 0
Thu Nov 3 13:18:51 2005 ARG tempLogin juca
Thu Nov 3 13:18:51 2005 ARG tempPassword saci10
Thu Nov 3 13:18:51 2005 ARG testnumber1
Thu Nov 3 13:18:51 2005 ARG testnumber2
Thu Nov 3 13:18:51 2005 ARG user
Thu Nov 3 13:18:51 2005 ARG verbose 1
Thu Nov 3 13:18:51 2005 ARG veryVerbose 0
Thu Nov 3 13:18:51 2005 AlgInvocationId 59
Thu Nov 3 13:18:51 2005 COMMIT commit off
Thu Nov 3 13:18:51 2005 There are 12 entries in the source
database hashThu Nov 3 13:20:11 2005 There are 7251218 gi to
taxon_id pairs
DBI connect('host=3Dlocalhost.localdomain;sid=3Dgustest','juca',...)
failed: invalid connection option "sid"
at /gus/GUS/gus_home/lib/perl/GUS/Supported/Plugin/LoadNRDB.pm line 320
ERROR:
Can't call method "do" on an undefined value at
/gus/GUS/gus_home/lib/perl/GUS/Supported/Plugin/LoadNRDB.pm line 323.
STACK TRACE:
at /gus/GUS/gus_home/lib/perl/GUS/Supported/Plugin/LoadNRDB.pm line 323
GUS::Supported::Plugin::LoadNRDB::makeTempTable('GUS::Supported::Pl=
ugin::LoadNRDB=3DHASH(0x99a1504)','HASH(0x9f517fc)','HASH(0x9a39270)')
called at /gus/GUS/gus_home/lib/perl/GUS/Supported/Plugin/LoadNRDB.pm
line 210
GUS::Supported::Plugin::LoadNRDB::run('GUS::Supported::Plugin::Load=
NRDB=3DHASH(0x99a1504)','HASH(0xa13d12c)')
called at /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm
line 520
eval {...} called at
/gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 512
GUS::PluginMgr::GusApplication::doMajorMode_RunOrReport('GUS::Plugi=
nMgr::GusApplication=3DHASH(0x9980c18)','GUS::Supported::Plugin::LoadNRDB',=
1)
called at /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm
line 430
GUS::PluginMgr::GusApplication::doMajorMode_Run('GUS::PluginMgr::Gu=
sApplication=3DHASH(0x9980c18)','GUS::Supported::Plugin::LoadNRDB')
called at /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm
line 337
GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApp=
lication=3DHASH(0x9980c18)','GUS::Supported::Plugin::LoadNRDB')
called at /gus/GUS/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm
line 246
GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApp=
lication=3DHASH(0x9980c18)','ARRAY(0x99946a8)')
called at /gus/GUS/gus_home/bin/ga line 11
That option 'sid' is listed on the help file, so why is that the error?
Thanks for the attention,
Henrique Cesar Lemos Juc=E1 - http://www.bioinformatica.ufsc.br
"As soon as you concern yourself with the "good" and "bad" of your fellows,
you create an opening in your heart for maliciousness to enter. Testing,
competing with, and criticizing others weaken and defeat you."
Morihei Ueshiba, O-Sensei (1883-1969)
|
|
From: Steve F. <sfi...@pc...> - 2005-11-02 22:54:37
|
Jian- this seems reasonable to me. steve Jian Lu wrote: > Hi Folks, > > We have such a situation that when running our annotation pipeline, we > need to know the relationships between external database identifiers > and EC numbers. Here is an example of TIGRAFAM info data: TIGR02496.INFO > ID NrdJ > AC TIGR02496 > DE ribonucleoside diphosphate reductase, B12-dependent > AU Selengut J > TC 855.00 855.00 > NC 120.00 120.00 > AL clustalw > IT equivalog > EN ribonucleoside diphosphate reductase, B12-dependent > GS nrdJ > EC 1.17.4.1 > TP TIGRFAMs > > We have EC numbers loaded into SRes.EnzymeClass and TIGRFAM ids into > SRes.ExternalDatabaseEntry, but we couldn't find a place within GUS > schema to store the relationship of them. There is a table > DoTS.AASequenceEnzymeClass that could be linked to EC numbers, but it > requires aa_sequence_id which is not what we need. So we created a > table called DoTS.ECAssociation to store any id with relation to EC > numbers. This is very similar to gene ontology association > DoTS.GOAssociation. Any comment? > > create table DoTS.ECAssociation ( > ec_association_id number(10) not null, > table_id number(10) not null, > row_id number(10) not null, > enzyme_class_id number(12) not null, > review_status_id number(12), > ec_association_date date, > modification_date date not null, > user_read number(1) not null, > user_write number(1) not null, > group_read number(1) not null, > group_write number(1) not null, > other_read number(1) not null, > other_write number(1) not null, > row_user_id number(12) not null, > row_group_id number(4) not null, > row_project_id number(4) not null, > row_alg_invocation_id number(12) not null > ); > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
|
From: Jian Lu <jl...@vb...> - 2005-11-02 22:12:50
|
Hi Folks,
We have such a situation that when running our annotation pipeline, we
need to know the relationships between external database identifiers and
EC numbers. Here is an example of TIGRAFAM info data: TIGR02496.INFO
ID NrdJ
AC TIGR02496
DE ribonucleoside diphosphate reductase, B12-dependent
AU Selengut J
TC 855.00 855.00
NC 120.00 120.00
AL clustalw
IT equivalog
EN ribonucleoside diphosphate reductase, B12-dependent
GS nrdJ
EC 1.17.4.1
TP TIGRFAMs
We have EC numbers loaded into SRes.EnzymeClass and TIGRFAM ids into
SRes.ExternalDatabaseEntry, but we couldn't find a place within GUS
schema to store the relationship of them. There is a table
DoTS.AASequenceEnzymeClass that could be linked to EC numbers, but it
requires aa_sequence_id which is not what we need. So we created a table
called DoTS.ECAssociation to store any id with relation to EC numbers.
This is very similar to gene ontology association DoTS.GOAssociation.
Any comment?
create table DoTS.ECAssociation (
ec_association_id number(10) not null,
table_id number(10) not null,
row_id number(10) not null,
enzyme_class_id number(12) not null,
review_status_id number(12),
ec_association_date date,
modification_date date not null,
user_read number(1) not null,
user_write number(1) not null,
group_read number(1) not null,
group_write number(1) not null,
other_read number(1) not null,
other_write number(1) not null,
row_user_id number(12) not null,
row_group_id number(4) not null,
row_project_id number(4) not null,
row_alg_invocation_id number(12) not null
);
|
|
From: Steve F. <sfi...@pc...> - 2005-10-31 15:33:20
|
we could do that. the object layer could keep track of this. but: 1. not all writes go through the object layer. some use sql directly, and, it wouldn't be that easy to encapsulate that to enforce this 2. just tracking the tables written to isn't enough. the Undo-er also needs to know the order in which to do the deletes (up the child-parent tree). With *effort* we could: - upgrade the object layer so that it tracks all tables written - analyze the dependency graph of the tables, and encode that as meta data - get very fancy and attempt to encapsulate any direct sql writes in a system that tracks the tables written to in sum, i think the idea you are promoting is theoretically interesting. but, practically, i don't think we'll have the resources to implement it. A middle ground would be: 1. introduce a table called AlgorithmUndoTables. Each row would have a link to AlgorithmInvocation, the id of a row in TableInfo (ie, a pointer to a Table), and, an order_number indicating the order in which the table should be undone. 2. have ga call the undoTables() method on the plugin to fill in this table at plugin run time. In other words, still rely on the author to provide the correct ordered list of tables for undoing, but, instead of acquiring that information at Undo time, record it at plugin run time. The (only) advantage this provides over the current system is that a run of a plugin can be undone even if it was created by an earlier version of the plugin that affected different tables than the current one. This would be most useful in the context of plugin development where the set of tables affected might actually be changing rapidly. I think this change would make reasonable sense, and, is within reach. However, i still want to wait a bit, and see what unfolds with the use of the Undo plugin. For now, I'll add another risk to the documentation, which is that the Undo will only work if the current declaration of the undoTables matches what was run. Thanks for the good idea. steve Chris Topinka wrote: > What about requiring plugins to use table access methods that would > register that the plugin had been there? Maybe too restrictive? > > On 10/30/05, *Steve Fischer* <sfi...@pc... > <mailto:sfi...@pc...>> wrote: > > a table that tracked what rows were affected would be huge (it would > need a row for each row in the db). > > we could consider a table that tracked the tables affected, and > stay w/ > the current design that marks each row with the algorithm that > produced > it. the purpose of that would be to keep a record for later > undo-ing of > the tables a plugin affected. > > but, we would need to seriously justify such a design change. > the main > problem is that it is not really feasible to know rigorously what > tables > a plugin affected, as a plugin is an open-ended program that can call > other modules, and can write sql directly. therefore, we must > rely on > the author's claims, and, those are only so reliable. i would be > reluctant to write into an official sounding table data that is only > imperfectly reliable. > > the point of the Undoer is that it is at-your-own-risk. also, it is > expected to be used shortly after the plugin has been run. but, > we can > keep our eyes on it, now that we have it. perhaps over time we'll > see > the right solution. > > steve > > Chris Topinka wrote: > > > How about keeping a table that records the tables/rows affected by a > > plugin run? Maybe make it part of a relationship to the version? > > > > On 10/30/05, *Steve Fischer* <sfi...@pc... > <mailto:sfi...@pc...> > > <mailto:sfi...@pc... > <mailto:sfi...@pc...>>> wrote: > > > > oops, i had a typo. > > > > i meant to say "one could find every row in the database that a > > particular plugin introduced..." > > > > steve > > > > Steve Fischer wrote: > > > > > there is one algorithm_invocation_id per plugin run. > > > > > > in theory, one could find every row in the database that a > > particular > > > row introduced by checking every row for that > > > algorithm_invocation_id. the problem is that it would > take too > > much > > > time to do that. so, the compromise i implemented in the > > Undo-er is > > > that the author of the plugin manually specifies the > tables to > > search. > > > the tracking of the plugin version is very stringent. we store > > in the > > > database the md5 checksum of the plugin file. if the > plugin has > > > changed, then it is re-registered in the database. > > > > > > steve > > > > > > Chris Stoeckert wrote: > > > > > >>> Is there a way of enforcing plugin version tracking? I > guess what > > >>> I'm asking is, is there a way to detect if a plugin has > been > > >>> modified since its last use? > > >> > > >> > > >> Yes, through AlgorithmImplementation (AlgorithmInvocation > points to > > >> this table) > > >> see > > >> > > > http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation> > > > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation>> > > >> > > > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation> > > > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation>>> > > > >> > > >> > > >> Chris > > >> > > >> On Oct 30, 2005, at 12:55 PM, Chris Topinka wrote: > > >> > > >>> what about storing which row/tables were updated by an > > >>> algorithm_invocation_ids? I'm new to GUS. Is this done > already? > > >>> Am I correct in assuming that algorithm_invocation_ids > are created > > >>> every time a particular plugin (algorithm) is run or are > there > > >>> multiple algorithm_invocation_ids per plugin run? > > >>> Is there a way of enforcing plugin version tracking? I > guess what > > >>> I'm asking is, is there a way to detect if a plugin has > been > > >>> modified since its last use? > > >>> > > >>> > > >>> > > >>> On 10/30/05, *Steve Fischer* < sfi...@pc... > <mailto:sfi...@pc...> > > <mailto:sfi...@pc... > <mailto:sfi...@pc...>> > > >>> <mailto:sfi...@pc... > <mailto:sfi...@pc...> > > <mailto:sfi...@pc... > <mailto:sfi...@pc...>>>> wrote: > > >>> > > >>> i like the idea of checking the name of the > plugin. I'll > > do that. > > >>> > > >>> as far as the plugin evolving, i guess that is a > mirky area. > > >>> I'll add > > >>> that to the risks. My main answer is that I > envision Undo > > to be > > >>> applied > > >>> shortly after the data is loaded, so the presumption is > > that the > > >>> evolution is small and known. > > >>> > > >>> steve > > >>> > > >>> Jonathan Schug wrote: > > >>> > > >>> > Steve: > > >>> > > > >>> > Does the Undo plugin check to see that the > > >>> algorithm_invocation_ids > > >>> > belong to the target plugin? That would add a > measure of > > >>> safety. Of > > >>> > course we'd probably need an override if a plugin > has since > > >>> changed > > >>> > names. What if the plugin changes the tables it > touches. I > > >>> guess > > >>> > the undoTables() has to return a comprehensive list? > > >>> > > > >>> > Jonathan > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > Jonathan Schug - js...@pc... > <mailto:js...@pc...> > > <mailto:js...@pc... <mailto:js...@pc...>> > > >>> <mailto:js...@pc... > <mailto:js...@pc...> <mailto:js...@pc... > <mailto:js...@pc...>>> > > >>> > > > >>> > > > >>> > > > >>> > > ------------------------------------------------------- > > >>> > This SF.Net email is sponsored by the JBoss Inc. > > >>> > Get Certified Today * Register for a JBoss > Training Course > > >>> > Free Certification Exam for All Training Attendees > > Through End > > >>> of 2005 > > >>> > Visit http://www.jboss.com/services/certification > > <http://www.jboss.com/services/certification> for more > > >>> information > > >>> > _______________________________________________ > > >>> > Gusdev-gusdev mailing list > > >>> > Gus...@li... > <mailto:Gus...@li...> > > <mailto:Gus...@li... > <mailto:Gus...@li...>> > > >>> <mailto: Gus...@li... > <mailto:Gus...@li...> > > <mailto:Gus...@li... > <mailto:Gus...@li...>>> > > >>> > > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > >>> > <https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > <https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev>> > > >>> > > >>> > > >>> > > >>> ------------------------------------------------------- > > >>> This SF.Net email is sponsored by the JBoss Inc. > > >>> Get Certified Today * Register for a JBoss Training > Course > > >>> Free Certification Exam for All Training Attendees > Through > > End of > > >>> 2005 > > >>> Visit http://www.jboss.com/services/certification > > <http://www.jboss.com/services/certification > <http://www.jboss.com/services/certification>> for more > > >>> information > > >>> _______________________________________________ > > >>> Gusdev-gusdev mailing list > > >>> Gus...@li... > <mailto:Gus...@li...> > > <mailto:Gus...@li... > <mailto:Gus...@li...>> > > >>> <mailto: Gus...@li... > <mailto:Gus...@li...> > > <mailto:Gus...@li... > <mailto:Gus...@li...>>> > > >>> > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Christopher M. Topinka > > >>> NLM-BHIRT Predoctoral Fellow in Computer Science > > >>> 113 Life Sciences Center > > >>> University of Missouri > > >>> Columbia, MO 65211 > > >>> (573)-823-0616 > > >>> cmt...@mi... <mailto:cmt...@mi...> > <mailto: cmt...@mi... <mailto:cmt...@mi...>> > > <mailto:cmt...@mi... <mailto:cmt...@mi...> > <mailto:cmt...@mi... <mailto:cmt...@mi...>>> > > >> > > >> > > >> > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by the JBoss Inc. > > > Get Certified Today * Register for a JBoss Training Course > > > Free Certification Exam for All Training Attendees Through End > > of 2005 > > > Visit http://www.jboss.com/services/certification > <http://www.jboss.com/services/certification> > > <http://www.jboss.com/services/certification> for more > information > > > _______________________________________________ > > > Gusdev-gusdev mailing list > > > Gus...@li... > <mailto:Gus...@li...> > > <mailto:Gus...@li... > <mailto:Gus...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > > > > > > > -- > > Christopher M. Topinka > > NLM-BHIRT Predoctoral Fellow in Computer Science > > 113 Life Sciences Center > > University of Missouri > > Columbia, MO 65211 > > (573)-823-0616 > > cmt...@mi... <mailto:cmt...@mi...> > <mailto:cmt...@mi... <mailto:cmt...@mi...>> > > > > > -- > Christopher M. Topinka > NLM-BHIRT Predoctoral Fellow in Computer Science > 113 Life Sciences Center > University of Missouri > Columbia, MO 65211 > (573)-823-0616 > cmt...@mi... <mailto:cmt...@mi...> |
|
From: Chris T. <cmt...@gm...> - 2005-10-31 03:47:24
|
What about requiring plugins to use table access methods that would registe= r that the plugin had been there? Maybe too restrictive? On 10/30/05, Steve Fischer <sfi...@pc...> wrote: > > a table that tracked what rows were affected would be huge (it would > need a row for each row in the db). > > we could consider a table that tracked the tables affected, and stay w/ > the current design that marks each row with the algorithm that produced > it. the purpose of that would be to keep a record for later undo-ing of > the tables a plugin affected. > > but, we would need to seriously justify such a design change. the main > problem is that it is not really feasible to know rigorously what tables > a plugin affected, as a plugin is an open-ended program that can call > other modules, and can write sql directly. therefore, we must rely on > the author's claims, and, those are only so reliable. i would be > reluctant to write into an official sounding table data that is only > imperfectly reliable. > > the point of the Undoer is that it is at-your-own-risk. also, it is > expected to be used shortly after the plugin has been run. but, we can > keep our eyes on it, now that we have it. perhaps over time we'll see > the right solution. > > steve > > Chris Topinka wrote: > > > How about keeping a table that records the tables/rows affected by a > > plugin run? Maybe make it part of a relationship to the version? > > > > On 10/30/05, *Steve Fischer* <sfi...@pc... > > <mailto:sfi...@pc...>> wrote: > > > > oops, i had a typo. > > > > i meant to say "one could find every row in the database that a > > particular plugin introduced..." > > > > steve > > > > Steve Fischer wrote: > > > > > there is one algorithm_invocation_id per plugin run. > > > > > > in theory, one could find every row in the database that a > > particular > > > row introduced by checking every row for that > > > algorithm_invocation_id. the problem is that it would take too > > much > > > time to do that. so, the compromise i implemented in the > > Undo-er is > > > that the author of the plugin manually specifies the tables to > > search. > > > the tracking of the plugin version is very stringent. we store > > in the > > > database the md5 checksum of the plugin file. if the plugin has > > > changed, then it is re-registered in the database. > > > > > > steve > > > > > > Chris Stoeckert wrote: > > > > > >>> Is there a way of enforcing plugin version tracking? I guess what > > >>> I'm asking is, is there a way to detect if a plugin has been > > >>> modified since its last use? > > >> > > >> > > >> Yes, through AlgorithmImplementation (AlgorithmInvocation points to > > >> this table) > > >> see > > >> > > > http://www.gusdb.org/SchemaBrowser/table.htm?schema=3DCore&table=3DAlgori= thmImplementation > > < > http://www.gusdb.org/SchemaBrowser/table.htm?schema=3DCore&table=3DAlgori= thmImplementation > > > > >> > > < > http://www.gusdb.org/SchemaBrowser/table.htm?schema=3DCore&table=3DAlgori= thmImplementation > > < > http://www.gusdb.org/SchemaBrowser/table.htm?schema=3DCore&table=3DAlgori= thmImplementation > >> > > >> > > >> > > >> Chris > > >> > > >> On Oct 30, 2005, at 12:55 PM, Chris Topinka wrote: > > >> > > >>> what about storing which row/tables were updated by an > > >>> algorithm_invocation_ids? I'm new to GUS. Is this done already? > > >>> Am I correct in assuming that algorithm_invocation_ids are created > > >>> every time a particular plugin (algorithm) is run or are there > > >>> multiple algorithm_invocation_ids per plugin run? > > >>> Is there a way of enforcing plugin version tracking? I guess what > > >>> I'm asking is, is there a way to detect if a plugin has been > > >>> modified since its last use? > > >>> > > >>> > > >>> > > >>> On 10/30/05, *Steve Fischer* <sfi...@pc... > > <mailto:sfi...@pc...> > > >>> <mailto:sfi...@pc... > > <mailto:sfi...@pc...>>> wrote: > > >>> > > >>> i like the idea of checking the name of the plugin. I'll > > do that. > > >>> > > >>> as far as the plugin evolving, i guess that is a mirky area. > > >>> I'll add > > >>> that to the risks. My main answer is that I envision Undo > > to be > > >>> applied > > >>> shortly after the data is loaded, so the presumption is > > that the > > >>> evolution is small and known. > > >>> > > >>> steve > > >>> > > >>> Jonathan Schug wrote: > > >>> > > >>> > Steve: > > >>> > > > >>> > Does the Undo plugin check to see that the > > >>> algorithm_invocation_ids > > >>> > belong to the target plugin? That would add a measure of > > >>> safety. Of > > >>> > course we'd probably need an override if a plugin has since > > >>> changed > > >>> > names. What if the plugin changes the tables it touches. I > > >>> guess > > >>> > the undoTables() has to return a comprehensive list? > > >>> > > > >>> > Jonathan > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > Jonathan Schug - js...@pc... > > <mailto:js...@pc...> > > >>> <mailto:js...@pc... <mailto:js...@pc...>> > > >>> > > > >>> > > > >>> > > > >>> > ------------------------------------------------------- > > >>> > This SF.Net email is sponsored by the JBoss Inc. > > >>> > Get Certified Today * Register for a JBoss Training Course > > >>> > Free Certification Exam for All Training Attendees > > Through End > > >>> of 2005 > > >>> > Visit http://www.jboss.com/services/certification > > <http://www.jboss.com/services/certification> for more > > >>> information > > >>> > _______________________________________________ > > >>> > Gusdev-gusdev mailing list > > >>> > Gus...@li... > > <mailto:Gus...@li...> > > >>> <mailto:Gus...@li... > > <mailto:Gus...@li...>> > > >>> > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > >>> <https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev> > > >>> > > >>> > > >>> > > >>> ------------------------------------------------------- > > >>> This SF.Net email is sponsored by the JBoss Inc. > > >>> Get Certified Today * Register for a JBoss Training Course > > >>> Free Certification Exam for All Training Attendees Through > > End of > > >>> 2005 > > >>> Visit http://www.jboss.com/services/certification > > <http://www.jboss.com/services/certification> for more > > >>> information > > >>> _______________________________________________ > > >>> Gusdev-gusdev mailing list > > >>> Gus...@li... > > <mailto:Gus...@li...> > > >>> <mailto:Gus...@li... > > <mailto:Gus...@li...>> > > >>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Christopher M. Topinka > > >>> NLM-BHIRT Predoctoral Fellow in Computer Science > > >>> 113 Life Sciences Center > > >>> University of Missouri > > >>> Columbia, MO 65211 > > >>> (573)-823-0616 > > >>> cmt...@mi... <mailto:cmt...@mi...> > > <mailto:cmt...@mi... <mailto:cmt...@mi...>> > > >> > > >> > > >> > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by the JBoss Inc. > > > Get Certified Today * Register for a JBoss Training Course > > > Free Certification Exam for All Training Attendees Through End > > of 2005 > > > Visit http://www.jboss.com/services/certification > > <http://www.jboss.com/services/certification> for more information > > > _______________________________________________ > > > Gusdev-gusdev mailing list > > > Gus...@li... > > <mailto:Gus...@li...> > > > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > > > > > > > -- > > Christopher M. Topinka > > NLM-BHIRT Predoctoral Fellow in Computer Science > > 113 Life Sciences Center > > University of Missouri > > Columbia, MO 65211 > > (573)-823-0616 > > cmt...@mi... <mailto:cmt...@mi...> > > -- Christopher M. Topinka NLM-BHIRT Predoctoral Fellow in Computer Science 113 Life Sciences Center University of Missouri Columbia, MO 65211 (573)-823-0616 cmt...@mi... |
|
From: Steve F. <sfi...@pc...> - 2005-10-31 01:28:22
|
a table that tracked what rows were affected would be huge (it would need a row for each row in the db). we could consider a table that tracked the tables affected, and stay w/ the current design that marks each row with the algorithm that produced it. the purpose of that would be to keep a record for later undo-ing of the tables a plugin affected. but, we would need to seriously justify such a design change. the main problem is that it is not really feasible to know rigorously what tables a plugin affected, as a plugin is an open-ended program that can call other modules, and can write sql directly. therefore, we must rely on the author's claims, and, those are only so reliable. i would be reluctant to write into an official sounding table data that is only imperfectly reliable. the point of the Undoer is that it is at-your-own-risk. also, it is expected to be used shortly after the plugin has been run. but, we can keep our eyes on it, now that we have it. perhaps over time we'll see the right solution. steve Chris Topinka wrote: > How about keeping a table that records the tables/rows affected by a > plugin run? Maybe make it part of a relationship to the version? > > On 10/30/05, *Steve Fischer* <sfi...@pc... > <mailto:sfi...@pc...>> wrote: > > oops, i had a typo. > > i meant to say "one could find every row in the database that a > particular plugin introduced..." > > steve > > Steve Fischer wrote: > > > there is one algorithm_invocation_id per plugin run. > > > > in theory, one could find every row in the database that a > particular > > row introduced by checking every row for that > > algorithm_invocation_id. the problem is that it would take too > much > > time to do that. so, the compromise i implemented in the > Undo-er is > > that the author of the plugin manually specifies the tables to > search. > > the tracking of the plugin version is very stringent. we store > in the > > database the md5 checksum of the plugin file. if the plugin has > > changed, then it is re-registered in the database. > > > > steve > > > > Chris Stoeckert wrote: > > > >>> Is there a way of enforcing plugin version tracking? I guess what > >>> I'm asking is, is there a way to detect if a plugin has been > >>> modified since its last use? > >> > >> > >> Yes, through AlgorithmImplementation (AlgorithmInvocation points to > >> this table) > >> see > >> > http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation> > >> > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation>> > >> > >> > >> Chris > >> > >> On Oct 30, 2005, at 12:55 PM, Chris Topinka wrote: > >> > >>> what about storing which row/tables were updated by an > >>> algorithm_invocation_ids? I'm new to GUS. Is this done already? > >>> Am I correct in assuming that algorithm_invocation_ids are created > >>> every time a particular plugin (algorithm) is run or are there > >>> multiple algorithm_invocation_ids per plugin run? > >>> Is there a way of enforcing plugin version tracking? I guess what > >>> I'm asking is, is there a way to detect if a plugin has been > >>> modified since its last use? > >>> > >>> > >>> > >>> On 10/30/05, *Steve Fischer* <sfi...@pc... > <mailto:sfi...@pc...> > >>> <mailto:sfi...@pc... > <mailto:sfi...@pc...>>> wrote: > >>> > >>> i like the idea of checking the name of the plugin. I'll > do that. > >>> > >>> as far as the plugin evolving, i guess that is a mirky area. > >>> I'll add > >>> that to the risks. My main answer is that I envision Undo > to be > >>> applied > >>> shortly after the data is loaded, so the presumption is > that the > >>> evolution is small and known. > >>> > >>> steve > >>> > >>> Jonathan Schug wrote: > >>> > >>> > Steve: > >>> > > >>> > Does the Undo plugin check to see that the > >>> algorithm_invocation_ids > >>> > belong to the target plugin? That would add a measure of > >>> safety. Of > >>> > course we'd probably need an override if a plugin has since > >>> changed > >>> > names. What if the plugin changes the tables it touches. I > >>> guess > >>> > the undoTables() has to return a comprehensive list? > >>> > > >>> > Jonathan > >>> > > >>> > > >>> > > >>> > > >>> > Jonathan Schug - js...@pc... > <mailto:js...@pc...> > >>> <mailto:js...@pc... <mailto:js...@pc...>> > >>> > > >>> > > >>> > > >>> > ------------------------------------------------------- > >>> > This SF.Net email is sponsored by the JBoss Inc. > >>> > Get Certified Today * Register for a JBoss Training Course > >>> > Free Certification Exam for All Training Attendees > Through End > >>> of 2005 > >>> > Visit http://www.jboss.com/services/certification > <http://www.jboss.com/services/certification> for more > >>> information > >>> > _______________________________________________ > >>> > Gusdev-gusdev mailing list > >>> > Gus...@li... > <mailto:Gus...@li...> > >>> <mailto:Gus...@li... > <mailto:Gus...@li...>> > >>> > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > >>> <https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev> > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> This SF.Net email is sponsored by the JBoss Inc. > >>> Get Certified Today * Register for a JBoss Training Course > >>> Free Certification Exam for All Training Attendees Through > End of > >>> 2005 > >>> Visit http://www.jboss.com/services/certification > <http://www.jboss.com/services/certification> for more > >>> information > >>> _______________________________________________ > >>> Gusdev-gusdev mailing list > >>> Gus...@li... > <mailto:Gus...@li...> > >>> <mailto:Gus...@li... > <mailto:Gus...@li...>> > >>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > >>> > >>> > >>> > >>> > >>> -- > >>> Christopher M. Topinka > >>> NLM-BHIRT Predoctoral Fellow in Computer Science > >>> 113 Life Sciences Center > >>> University of Missouri > >>> Columbia, MO 65211 > >>> (573)-823-0616 > >>> cmt...@mi... <mailto:cmt...@mi...> > <mailto:cmt...@mi... <mailto:cmt...@mi...>> > >> > >> > >> > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course > > Free Certification Exam for All Training Attendees Through End > of 2005 > > Visit http://www.jboss.com/services/certification > <http://www.jboss.com/services/certification> for more information > > _______________________________________________ > > Gusdev-gusdev mailing list > > Gus...@li... > <mailto:Gus...@li...> > > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > > -- > Christopher M. Topinka > NLM-BHIRT Predoctoral Fellow in Computer Science > 113 Life Sciences Center > University of Missouri > Columbia, MO 65211 > (573)-823-0616 > cmt...@mi... <mailto:cmt...@mi...> |
|
From: Chris T. <cmt...@gm...> - 2005-10-31 00:55:04
|
How about keeping a table that records the tables/rows affected by a plugin run? Maybe make it part of a relationship to the version? On 10/30/05, Steve Fischer <sfi...@pc...> wrote: > > oops, i had a typo. > > i meant to say "one could find every row in the database that a > particular plugin introduced..." > > steve > > Steve Fischer wrote: > > > there is one algorithm_invocation_id per plugin run. > > > > in theory, one could find every row in the database that a particular > > row introduced by checking every row for that > > algorithm_invocation_id. the problem is that it would take too much > > time to do that. so, the compromise i implemented in the Undo-er is > > that the author of the plugin manually specifies the tables to search. > > the tracking of the plugin version is very stringent. we store in the > > database the md5 checksum of the plugin file. if the plugin has > > changed, then it is re-registered in the database. > > > > steve > > > > Chris Stoeckert wrote: > > > >>> Is there a way of enforcing plugin version tracking? I guess what > >>> I'm asking is, is there a way to detect if a plugin has been > >>> modified since its last use? > >> > >> > >> Yes, through AlgorithmImplementation (AlgorithmInvocation points to > >> this table) > >> see > >> > http://www.gusdb.org/SchemaBrowser/table.htm?schema=3DCore&table=3DAlgori= thmImplementation > >> < > http://www.gusdb.org/SchemaBrowser/table.htm?schema=3DCore&table=3DAlgori= thmImplementation > > > >> > >> > >> Chris > >> > >> On Oct 30, 2005, at 12:55 PM, Chris Topinka wrote: > >> > >>> what about storing which row/tables were updated by an > >>> algorithm_invocation_ids? I'm new to GUS. Is this done already? > >>> Am I correct in assuming that algorithm_invocation_ids are created > >>> every time a particular plugin (algorithm) is run or are there > >>> multiple algorithm_invocation_ids per plugin run? > >>> Is there a way of enforcing plugin version tracking? I guess what > >>> I'm asking is, is there a way to detect if a plugin has been > >>> modified since its last use? > >>> > >>> > >>> > >>> On 10/30/05, *Steve Fischer* <sfi...@pc... > >>> <mailto:sfi...@pc...>> wrote: > >>> > >>> i like the idea of checking the name of the plugin. I'll do that. > >>> > >>> as far as the plugin evolving, i guess that is a mirky area. > >>> I'll add > >>> that to the risks. My main answer is that I envision Undo to be > >>> applied > >>> shortly after the data is loaded, so the presumption is that the > >>> evolution is small and known. > >>> > >>> steve > >>> > >>> Jonathan Schug wrote: > >>> > >>> > Steve: > >>> > > >>> > Does the Undo plugin check to see that the > >>> algorithm_invocation_ids > >>> > belong to the target plugin? That would add a measure of > >>> safety. Of > >>> > course we'd probably need an override if a plugin has since > >>> changed > >>> > names. What if the plugin changes the tables it touches. I > >>> guess > >>> > the undoTables() has to return a comprehensive list? > >>> > > >>> > Jonathan > >>> > > >>> > > >>> > > >>> > > >>> > Jonathan Schug - js...@pc... > >>> <mailto:js...@pc...> > >>> > > >>> > > >>> > > >>> > ------------------------------------------------------- > >>> > This SF.Net email is sponsored by the JBoss Inc. > >>> > Get Certified Today * Register for a JBoss Training Course > >>> > Free Certification Exam for All Training Attendees Through End > >>> of 2005 > >>> > Visit http://www.jboss.com/services/certification for more > >>> information > >>> > _______________________________________________ > >>> > Gusdev-gusdev mailing list > >>> > Gus...@li... > >>> <mailto:Gus...@li...> > >>> > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > >>> <https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev> > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> This SF.Net email is sponsored by the JBoss Inc. > >>> Get Certified Today * Register for a JBoss Training Course > >>> Free Certification Exam for All Training Attendees Through End of > >>> 2005 > >>> Visit http://www.jboss.com/services/certification for more > >>> information > >>> _______________________________________________ > >>> Gusdev-gusdev mailing list > >>> Gus...@li... > >>> <mailto:Gus...@li...> > >>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > >>> > >>> > >>> > >>> > >>> -- > >>> Christopher M. Topinka > >>> NLM-BHIRT Predoctoral Fellow in Computer Science > >>> 113 Life Sciences Center > >>> University of Missouri > >>> Columbia, MO 65211 > >>> (573)-823-0616 > >>> cmt...@mi... <mailto:cmt...@mi...> > >> > >> > >> > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course > > Free Certification Exam for All Training Attendees Through End of 2005 > > Visit http://www.jboss.com/services/certification for more information > > _______________________________________________ > > Gusdev-gusdev mailing list > > Gus...@li... > > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > -- Christopher M. Topinka NLM-BHIRT Predoctoral Fellow in Computer Science 113 Life Sciences Center University of Missouri Columbia, MO 65211 (573)-823-0616 cmt...@mi... |
|
From: Steve F. <sfi...@pc...> - 2005-10-31 00:30:51
|
oops, i had a typo. i meant to say "one could find every row in the database that a particular plugin introduced..." steve Steve Fischer wrote: > there is one algorithm_invocation_id per plugin run. > > in theory, one could find every row in the database that a particular > row introduced by checking every row for that > algorithm_invocation_id. the problem is that it would take too much > time to do that. so, the compromise i implemented in the Undo-er is > that the author of the plugin manually specifies the tables to search. > the tracking of the plugin version is very stringent. we store in the > database the md5 checksum of the plugin file. if the plugin has > changed, then it is re-registered in the database. > > steve > > Chris Stoeckert wrote: > >>> Is there a way of enforcing plugin version tracking? I guess what >>> I'm asking is, is there a way to detect if a plugin has been >>> modified since its last use? >> >> >> Yes, through AlgorithmImplementation (AlgorithmInvocation points to >> this table) >> see >> http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation >> <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation> >> >> >> Chris >> >> On Oct 30, 2005, at 12:55 PM, Chris Topinka wrote: >> >>> what about storing which row/tables were updated by an >>> algorithm_invocation_ids? I'm new to GUS. Is this done already? >>> Am I correct in assuming that algorithm_invocation_ids are created >>> every time a particular plugin (algorithm) is run or are there >>> multiple algorithm_invocation_ids per plugin run? >>> Is there a way of enforcing plugin version tracking? I guess what >>> I'm asking is, is there a way to detect if a plugin has been >>> modified since its last use? >>> >>> >>> >>> On 10/30/05, *Steve Fischer* <sfi...@pc... >>> <mailto:sfi...@pc...>> wrote: >>> >>> i like the idea of checking the name of the plugin. I'll do that. >>> >>> as far as the plugin evolving, i guess that is a mirky area. >>> I'll add >>> that to the risks. My main answer is that I envision Undo to be >>> applied >>> shortly after the data is loaded, so the presumption is that the >>> evolution is small and known. >>> >>> steve >>> >>> Jonathan Schug wrote: >>> >>> > Steve: >>> > >>> > Does the Undo plugin check to see that the >>> algorithm_invocation_ids >>> > belong to the target plugin? That would add a measure of >>> safety. Of >>> > course we'd probably need an override if a plugin has since >>> changed >>> > names. What if the plugin changes the tables it touches. I >>> guess >>> > the undoTables() has to return a comprehensive list? >>> > >>> > Jonathan >>> > >>> > >>> > >>> > >>> > Jonathan Schug - js...@pc... >>> <mailto:js...@pc...> >>> > >>> > >>> > >>> > ------------------------------------------------------- >>> > This SF.Net email is sponsored by the JBoss Inc. >>> > Get Certified Today * Register for a JBoss Training Course >>> > Free Certification Exam for All Training Attendees Through End >>> of 2005 >>> > Visit http://www.jboss.com/services/certification for more >>> information >>> > _______________________________________________ >>> > Gusdev-gusdev mailing list >>> > Gus...@li... >>> <mailto:Gus...@li...> >>> > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >>> <https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by the JBoss Inc. >>> Get Certified Today * Register for a JBoss Training Course >>> Free Certification Exam for All Training Attendees Through End of >>> 2005 >>> Visit http://www.jboss.com/services/certification for more >>> information >>> _______________________________________________ >>> Gusdev-gusdev mailing list >>> Gus...@li... >>> <mailto:Gus...@li...> >>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >>> >>> >>> >>> >>> -- >>> Christopher M. Topinka >>> NLM-BHIRT Predoctoral Fellow in Computer Science >>> 113 Life Sciences Center >>> University of Missouri >>> Columbia, MO 65211 >>> (573)-823-0616 >>> cmt...@mi... <mailto:cmt...@mi...> >> >> >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
|
From: Steve F. <sfi...@pc...> - 2005-10-30 23:57:34
|
there is one algorithm_invocation_id per plugin run. in theory, one could find every row in the database that a particular row introduced by checking every row for that algorithm_invocation_id. the problem is that it would take too much time to do that. so, the compromise i implemented in the Undo-er is that the author of the plugin manually specifies the tables to search. the tracking of the plugin version is very stringent. we store in the database the md5 checksum of the plugin file. if the plugin has changed, then it is re-registered in the database. steve Chris Stoeckert wrote: >> Is there a way of enforcing plugin version tracking? I guess what >> I'm asking is, is there a way to detect if a plugin has been modified >> since its last use? > > Yes, through AlgorithmImplementation (AlgorithmInvocation points to > this table) > see > http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation > <http://www.gusdb.org/SchemaBrowser/table.htm?schema=Core&table=AlgorithmImplementation> > > Chris > > On Oct 30, 2005, at 12:55 PM, Chris Topinka wrote: > >> what about storing which row/tables were updated by an >> algorithm_invocation_ids? I'm new to GUS. Is this done already? Am >> I correct in assuming that algorithm_invocation_ids are created every >> time a particular plugin (algorithm) is run or are there multiple >> algorithm_invocation_ids per plugin run? >> >> Is there a way of enforcing plugin version tracking? I guess what >> I'm asking is, is there a way to detect if a plugin has been modified >> since its last use? >> >> >> >> On 10/30/05, *Steve Fischer* <sfi...@pc... >> <mailto:sfi...@pc...>> wrote: >> >> i like the idea of checking the name of the plugin. I'll do that. >> >> as far as the plugin evolving, i guess that is a mirky area. >> I'll add >> that to the risks. My main answer is that I envision Undo to be >> applied >> shortly after the data is loaded, so the presumption is that the >> evolution is small and known. >> >> steve >> >> Jonathan Schug wrote: >> >> > Steve: >> > >> > Does the Undo plugin check to see that the >> algorithm_invocation_ids >> > belong to the target plugin? That would add a measure of >> safety. Of >> > course we'd probably need an override if a plugin has since changed >> > names. What if the plugin changes the tables it touches. I guess >> > the undoTables() has to return a comprehensive list? >> > >> > Jonathan >> > >> > >> > >> > >> > Jonathan Schug - js...@pc... >> <mailto:js...@pc...> >> > >> > >> > >> > ------------------------------------------------------- >> > This SF.Net email is sponsored by the JBoss Inc. >> > Get Certified Today * Register for a JBoss Training Course >> > Free Certification Exam for All Training Attendees Through End >> of 2005 >> > Visit http://www.jboss.com/services/certification for more >> information >> > _______________________________________________ >> > Gusdev-gusdev mailing list >> > Gus...@li... >> <mailto:Gus...@li...> >> > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >> <https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. >> Get Certified Today * Register for a JBoss Training Course >> Free Certification Exam for All Training Attendees Through End of >> 2005 >> Visit http://www.jboss.com/services/certification for more >> information >> _______________________________________________ >> Gusdev-gusdev mailing list >> Gus...@li... >> <mailto:Gus...@li...> >> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >> >> >> >> >> -- >> Christopher M. Topinka >> NLM-BHIRT Predoctoral Fellow in Computer Science >> 113 Life Sciences Center >> University of Missouri >> Columbia, MO 65211 >> (573)-823-0616 >> cmt...@mi... <mailto:cmt...@mi...> > > |
|
From: Chris S. <sto...@pc...> - 2005-10-30 18:34:35
|
> Is there a way of enforcing plugin version tracking? I guess what > I'm asking is, is there a way to detect if a plugin has been > modified since its last use? Yes, through AlgorithmImplementation (AlgorithmInvocation points to this table) see http://www.gusdb.org/SchemaBrowser/table.htm? schema=Core&table=AlgorithmImplementation Chris On Oct 30, 2005, at 12:55 PM, Chris Topinka wrote: > what about storing which row/tables were updated by an > algorithm_invocation_ids? I'm new to GUS. Is this done already? > Am I correct in assuming that algorithm_invocation_ids are created > every time a particular plugin (algorithm) is run or are there > multiple algorithm_invocation_ids per plugin run? > > Is there a way of enforcing plugin version tracking? I guess what > I'm asking is, is there a way to detect if a plugin has been > modified since its last use? > > > > On 10/30/05, Steve Fischer <sfi...@pc...> wrote: > i like the idea of checking the name of the plugin. I'll do that. > > as far as the plugin evolving, i guess that is a mirky area. I'll > add > that to the risks. My main answer is that I envision Undo to be > applied > shortly after the data is loaded, so the presumption is that the > evolution is small and known. > > steve > > Jonathan Schug wrote: > > > Steve: > > > > Does the Undo plugin check to see that the algorithm_invocation_ids > > belong to the target plugin? That would add a measure of > safety. Of > > course we'd probably need an override if a plugin has since changed > > names. What if the plugin changes the tables it touches. I guess > > the undoTables() has to return a comprehensive list? > > > > Jonathan > > > > > > > > > > Jonathan Schug - js...@pc... > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course > > Free Certification Exam for All Training Attendees Through End of > 2005 > > Visit http://www.jboss.com/services/certification for more > information > > _______________________________________________ > > Gusdev-gusdev mailing list > > Gus...@li... > > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > -- > Christopher M. Topinka > NLM-BHIRT Predoctoral Fellow in Computer Science > 113 Life Sciences Center > University of Missouri > Columbia, MO 65211 > (573)-823-0616 > cmt...@mi... |
|
From: Chris T. <cmt...@gm...> - 2005-10-30 17:56:59
|
what about storing which row/tables were updated by an algorithm_invocation_ids? I'm new to GUS. Is this done already? Am I correc= t in assuming that algorithm_invocation_ids are created every time a particular plugin (algorithm) is run or are there multiple algorithm_invocation_ids per plugin run? Is there a way of enforcing plugin version tracking? I guess what I'm askin= g is, is there a way to detect if a plugin has been modified since its last use? On 10/30/05, Steve Fischer <sfi...@pc...> wrote: > > i like the idea of checking the name of the plugin. I'll do that. > > as far as the plugin evolving, i guess that is a mirky area. I'll add > that to the risks. My main answer is that I envision Undo to be applied > shortly after the data is loaded, so the presumption is that the > evolution is small and known. > > steve > > Jonathan Schug wrote: > > > Steve: > > > > Does the Undo plugin check to see that the algorithm_invocation_ids > > belong to the target plugin? That would add a measure of safety. Of > > course we'd probably need an override if a plugin has since changed > > names. What if the plugin changes the tables it touches. I guess > > the undoTables() has to return a comprehensive list? > > > > Jonathan > > > > > > > > > > Jonathan Schug - js...@pc... > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course > > Free Certification Exam for All Training Attendees Through End of 2005 > > Visit http://www.jboss.com/services/certification for more information > > _______________________________________________ > > Gusdev-gusdev mailing list > > Gus...@li... > > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > -- Christopher M. Topinka NLM-BHIRT Predoctoral Fellow in Computer Science 113 Life Sciences Center University of Missouri Columbia, MO 65211 (573)-823-0616 cmt...@mi... |
|
From: Steve F. <sfi...@pc...> - 2005-10-30 13:40:55
|
i like the idea of checking the name of the plugin. I'll do that. as far as the plugin evolving, i guess that is a mirky area. I'll add that to the risks. My main answer is that I envision Undo to be applied shortly after the data is loaded, so the presumption is that the evolution is small and known. steve Jonathan Schug wrote: > Steve: > > Does the Undo plugin check to see that the algorithm_invocation_ids > belong to the target plugin? That would add a measure of safety. Of > course we'd probably need an override if a plugin has since changed > names. What if the plugin changes the tables it touches. I guess > the undoTables() has to return a comprehensive list? > > Jonathan > > > > > Jonathan Schug - js...@pc... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
|
From: Jonathan S. <js...@pc...> - 2005-10-30 13:24:28
|
Steve: Does the Undo plugin check to see that the algorithm_invocation_ids belong to the target plugin? That would add a measure of safety. Of course we'd probably need an override if a plugin has since changed names. What if the plugin changes the tables it touches. I guess the undoTables() has to return a comprehensive list? Jonathan Jonathan Schug - js...@pc... |
|
From: Steve F. <sfi...@pc...> - 2005-10-29 12:05:58
|
i have adjusted the Undo api.
Here is the usage from the Undo plugin:
DESCRIPTION
The Undo plugin is very simple:
- it takes a plugin name and a list of algorithm_invocation_ids as
arguments
- when it runs, it calls a method on the target plugin:
$targetPlugin->undoTables()
- if the target plugin has not defined such a method, Undo will fail.
- if it has, then that method returns a list of tables to undo
from. Undo will remove fr
om each of those tables any rows whose row_alg_invocation_id is in the
list supplied on the com
mand line. The order of the tables in the list returned by undoTables()
must be such that chil
d tables come before parent tables. Otherwise you will get constraint
violations.
- Undo also deletes from AlgorithmParam and AlgorithmInvocation.
- All deletes are performed as part of one trancation. The
deletes are only commited if
Undo is run with --commit
This is something of a use-at-your-own-risk plugin.
The risks are:
1. you will mistakenly undo an incorrect algorithm_invocation_id,
thereby losing valuable
data
2. the undoTables() method in the target plugin could be written
incorrectly such that it
forgets some tables. There is some protection against this because
most tables that a plugin
writes to are child tables. It is not possible to forget those because
that would cause a cons
traint violation. It is only a problem if the Undo forgets to delete
from tables that have no
parents (or whose parents are also forgotten).
The advantages are:
1. a correctly written undoTables() method is much more
trustworthy than deleting by hand
2. undoing becomes doable
Steve Fischer wrote:
> folks-
>
> I have added a new plugin to Community:
> GUS::Community::Plugin::Undo
>
> It is a simple hook to allow other (real) plugins to undo the changes
> they have made to the database.
>
> The Undo plugin is very simple:
> - it takes a plugin name and a list of algorithm_invocation_ids as
> arguments
> - when it runs, it calls a method on the target plugin:
> $targetPlugin->undo($algInvIds, $dbh)
> - if the target plugin has not defined such a method, Undo will fail.
> - if it has, then that method is responsible for performing the
> undo. - it also provides a convenient method
> GUS::Community::Plugin::Undo::deleteFromTable($table, $algInvIds,
> $dbh). This method removes from the specified table all rows with any
> of the specified algortithm_invocation_ids.
>
> The strategy of an plugin's undo method should be:
> 1. call deleteFromTable on every table that it writes rows into
> (either directly or indirectly)
> 2. do so in the proper order, so that children are deleted before
> parents (otherwise you'll get constraint violations)
> 3. some tables will need special processing. For example, deleting
> from tables that have links to themselves (eg NAFeature) must either
> proceed from child to parent (which is tricky), or, if the links are
> nullable, must have those links deleted first, before the rows are
> deleted.
>
> This is something of a use-at-your-own-risk plugin.
> The risks are:
> 1. you will mistakenly remove an incorrect algorithm_invocation_id,
> thereby losing valuable data
> 2. the undo method in the target plugin could be written incorrectly
> such that it forgets to delete from some tables. There is some
> protection against this because most tables that a plugin writes to
> are child tables. It is not possible to forget those because that
> would cause a constraint violation. It is only a problem if the Undo
> forgets to delete from tables that have no parents (or whose parents
> are also forgotten).
>
> The advantages are:
> 1. a correctly written undo() method is much more trustworthy than
> deleting by hand
> 2. undoing becomes doable
>
> Depending on how things turn out, we may move this to Supported.
>
> Feedback?
>
> Steve
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
|
|
From: Steve F. <sfi...@pc...> - 2005-10-29 02:27:16
|
folks- I have added a new plugin to Community: GUS::Community::Plugin::Undo It is a simple hook to allow other (real) plugins to undo the changes they have made to the database. The Undo plugin is very simple: - it takes a plugin name and a list of algorithm_invocation_ids as arguments - when it runs, it calls a method on the target plugin: $targetPlugin->undo($algInvIds, $dbh) - if the target plugin has not defined such a method, Undo will fail. - if it has, then that method is responsible for performing the undo. - it also provides a convenient method GUS::Community::Plugin::Undo::deleteFromTable($table, $algInvIds, $dbh). This method removes from the specified table all rows with any of the specified algortithm_invocation_ids. The strategy of an plugin's undo method should be: 1. call deleteFromTable on every table that it writes rows into (either directly or indirectly) 2. do so in the proper order, so that children are deleted before parents (otherwise you'll get constraint violations) 3. some tables will need special processing. For example, deleting from tables that have links to themselves (eg NAFeature) must either proceed from child to parent (which is tricky), or, if the links are nullable, must have those links deleted first, before the rows are deleted. This is something of a use-at-your-own-risk plugin. The risks are: 1. you will mistakenly remove an incorrect algorithm_invocation_id, thereby losing valuable data 2. the undo method in the target plugin could be written incorrectly such that it forgets to delete from some tables. There is some protection against this because most tables that a plugin writes to are child tables. It is not possible to forget those because that would cause a constraint violation. It is only a problem if the Undo forgets to delete from tables that have no parents (or whose parents are also forgotten). The advantages are: 1. a correctly written undo() method is much more trustworthy than deleting by hand 2. undoing becomes doable Depending on how things turn out, we may move this to Supported. Feedback? Steve |
|
From: Y. T. G. <yg...@pc...> - 2005-10-28 16:52:59
|
On a fresh $GUS_HOME (possibly first attempt to install GUS software and the user is new to GUS), the GUS installer will simply complain that $GUS_HOME/config/gus.config does not exist. I have checked in a fix to the GUS installer to give explicit instruction on what to do when that happens (copying from the sample file and make appropriate edits if necessary). -Thomas > -----Original Message----- > From: gus...@li... > [mailto:gus...@li...] On Behalf > Of Michael Saffitz > Sent: Friday, October 28, 2005 10:43 AM > To: Junmin Liu > Cc: Gusdev gusdev-gusdev; ApiDB Project Mailing List; cbil > cb...@pc... > Subject: [GUSDEV] Re: [CBIL] GUS Config Changes > > > > I've had a few questions about this-- sorry my previous email wasn't > clearer: > > When you first download/checkout GUS, you will have a project_home > with the install component that contains gus.config.sample. > You must > manually copy this to gus_home/config/gus.config and edit it as > appropriate before running the installer. All GUS components > now use > that as a single point of configuration. > > $GUS_HOME/config/gus.config will never be overwritten since there's > no automatic process to copy it. $PROJECT_HOME/install/gus.config > will never be read since it's an deprecated configuration method. > > There is ONLY ONE configuration file!! $GUS_HOME/config/ > gus.config It is created manually. All other gus.config or > gus.property files are ignored!! > > Hope this is more clear :) > > Mike > > On Oct 28, 2005, at 11:36 AM, Junmin Liu wrote: > > > Hi, Mike, > > > > > >> ****** All GUS configuration* now comes from $GUS_HOME/config/ > >> gus.config. $GUS_CONFIG_FILE is no longer used anywhere in the > >> codebase. > >> > >> $GUS_HOME/config/gus.config is created at build time from > >> $PROJECT_HOME/install/gus.config. Thus, you should make changes > >> > > > > Will $GUS_HOME/config/gus.config be overwritten every time we > > change the $PROJECT_HOME/install/gus.config? I think months ago I > > complained about this bug (http://sourceforge.net/mailarchive/ > > message.php?msg_id=11820770), and you said it is feature not a bug. > > > > So is it still a feature now, which is the $GUS_HOME/config/ > > gus.config will not be overwritten after being genetated? > > > > ---junmin > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through > End of 2005 Visit http://www.jboss.com/services/certification > for more information _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > |
|
From: Junmin L. <ju...@pc...> - 2005-10-28 15:55:42
|
> I see. I think my previous email said: "$GUS_HOME/config/gus.config is a typo: "my previous email" should be "your previous email". > created at build time from $PROJECT_HOME/install/gus.config." It just > confused me. > > Probably we should say, "Manually created $GUS_HOME/config/gus.config, > using gus.config.sample in project_home as an example". > > --junmin > > > > On Fri, 28 Oct 2005, Michael Saffitz wrote: > >> >> I've had a few questions about this-- sorry my previous email wasn't clearer: >> >> When you first download/checkout GUS, you will have a project_home with the >> install component that contains gus.config.sample. You must manually copy >> this to gus_home/config/gus.config and edit it as appropriate before running >> the installer. All GUS components now use that as a single point of >> configuration. >> >> $GUS_HOME/config/gus.config will never be overwritten since there's no >> automatic process to copy it. $PROJECT_HOME/install/gus.config will never be >> read since it's an deprecated configuration method. >> >> There is ONLY ONE configuration file!! $GUS_HOME/config/gus.config It is >> created manually. All other gus.config or gus.property files are ignored!! >> >> Hope this is more clear :) >> >> Mike >> >> On Oct 28, 2005, at 11:36 AM, Junmin Liu wrote: >> >>> Hi, Mike, >>> >>> >>>> ****** All GUS configuration* now comes from $GUS_HOME/config/ >>>> gus.config. $GUS_CONFIG_FILE is no longer used anywhere in the >>>> codebase. >>>> >>>> $GUS_HOME/config/gus.config is created at build time from >>>> $PROJECT_HOME/install/gus.config. Thus, you should make changes >>>> >>> >>> Will $GUS_HOME/config/gus.config be overwritten every time we change the >>> $PROJECT_HOME/install/gus.config? I think months ago I complained about >>> this bug (http://sourceforge.net/mailarchive/message.php?msg_id=11820770), >>> and you said it is feature not a bug. >>> >>> So is it still a feature now, which is the $GUS_HOME/config/gus.config will >>> not be overwritten after being genetated? >>> >>> ---junmin >>> >> > _______________________________________________ > CBIL mailing list > CB...@pc... > https://mail.pcbi.upenn.edu/mailman/listinfo/cbil > |
|
From: Junmin L. <ju...@pc...> - 2005-10-28 15:49:13
|
I see. I think my previous email said: "$GUS_HOME/config/gus.config is created at build time from $PROJECT_HOME/install/gus.config." It just confused me. Probably we should say, "Manually created $GUS_HOME/config/gus.config, using gus.config.sample in project_home as an example". --junmin On Fri, 28 Oct 2005, Michael Saffitz wrote: > > I've had a few questions about this-- sorry my previous email wasn't clearer: > > When you first download/checkout GUS, you will have a project_home with the > install component that contains gus.config.sample. You must manually copy > this to gus_home/config/gus.config and edit it as appropriate before running > the installer. All GUS components now use that as a single point of > configuration. > > $GUS_HOME/config/gus.config will never be overwritten since there's no > automatic process to copy it. $PROJECT_HOME/install/gus.config will never be > read since it's an deprecated configuration method. > > There is ONLY ONE configuration file!! $GUS_HOME/config/gus.config It is > created manually. All other gus.config or gus.property files are ignored!! > > Hope this is more clear :) > > Mike > > On Oct 28, 2005, at 11:36 AM, Junmin Liu wrote: > >> Hi, Mike, >> >> >>> ****** All GUS configuration* now comes from $GUS_HOME/config/ >>> gus.config. $GUS_CONFIG_FILE is no longer used anywhere in the >>> codebase. >>> >>> $GUS_HOME/config/gus.config is created at build time from >>> $PROJECT_HOME/install/gus.config. Thus, you should make changes >>> >> >> Will $GUS_HOME/config/gus.config be overwritten every time we change the >> $PROJECT_HOME/install/gus.config? I think months ago I complained about >> this bug (http://sourceforge.net/mailarchive/message.php?msg_id=11820770), >> and you said it is feature not a bug. >> >> So is it still a feature now, which is the $GUS_HOME/config/gus.config will >> not be overwritten after being genetated? >> >> ---junmin >> > |
|
From: Michael S. <msa...@pc...> - 2005-10-28 15:42:53
|
I've had a few questions about this-- sorry my previous email wasn't clearer: When you first download/checkout GUS, you will have a project_home with the install component that contains gus.config.sample. You must manually copy this to gus_home/config/gus.config and edit it as appropriate before running the installer. All GUS components now use that as a single point of configuration. $GUS_HOME/config/gus.config will never be overwritten since there's no automatic process to copy it. $PROJECT_HOME/install/gus.config will never be read since it's an deprecated configuration method. There is ONLY ONE configuration file!! $GUS_HOME/config/ gus.config It is created manually. All other gus.config or gus.property files are ignored!! Hope this is more clear :) Mike On Oct 28, 2005, at 11:36 AM, Junmin Liu wrote: > Hi, Mike, > > >> ****** All GUS configuration* now comes from $GUS_HOME/config/ >> gus.config. $GUS_CONFIG_FILE is no longer used anywhere in the >> codebase. >> >> $GUS_HOME/config/gus.config is created at build time from >> $PROJECT_HOME/install/gus.config. Thus, you should make changes >> > > Will $GUS_HOME/config/gus.config be overwritten every time we > change the $PROJECT_HOME/install/gus.config? I think months ago I > complained about this bug (http://sourceforge.net/mailarchive/ > message.php?msg_id=11820770), and you said it is feature not a bug. > > So is it still a feature now, which is the $GUS_HOME/config/ > gus.config will not be overwritten after being genetated? > > ---junmin > |
|
From: Junmin L. <ju...@pc...> - 2005-10-28 15:37:10
|
Hi, Mike, > ****** All GUS configuration* now comes from $GUS_HOME/config/ > gus.config. $GUS_CONFIG_FILE is no longer used anywhere in the > codebase. > > $GUS_HOME/config/gus.config is created at build time from > $PROJECT_HOME/install/gus.config. Thus, you should make changes Will $GUS_HOME/config/gus.config be overwritten every time we change the $PROJECT_HOME/install/gus.config? I think months ago I complained about this bug (http://sourceforge.net/mailarchive/message.php?msg_id=11820770), and you said it is feature not a bug. So is it still a feature now, which is the $GUS_HOME/config/gus.config will not be overwritten after being genetated? ---junmin |
|
From: Michael S. <msa...@pc...> - 2005-10-28 14:18:06
|
Yes, this will be done manually. In 3.5 this file was manually created from gus.config.sample in install. Now, it's exactly the same, it's just manually created in a new spot (in $GUS_HOME, not in $PROJECT_HOME). I'll move all further discussion to gusdev so folks don't keep getting repeats of emails. --Mike On Oct 28, 2005, at 10:04 AM, Deborah Pinney wrote: > Michael Saffitz wrote: > > >> One additional change: >> >> At install time, $PROJECT_HOME/install/gus.config.sample should >> be moved and configured to $GUS_HOME/config/gus.config. This >> file (in $GUS_HOME) will then be the sole configuration for GUS. >> >> > This should be done manually? build = install ? > > >> No components in GUS will use $PROJECT_HOME/install/gus.config >> anymore, nor will it automatically be copied to $GUS_HOME/config/ >> gus.config >> >> --Mike >> >> On Oct 27, 2005, at 10:05 PM, Michael Saffitz wrote: >> >> >> >>> All, >>> >>> I've finally fixed the long standing and often confusion generating >>> issue of properly configuring GUS. This change should be relatively >>> minor, and full details are below, but I wanted to make sure >>> everyone >>> was clear. >>> >>> Short Version: >>> >>> ****** All GUS configuration* now comes from $GUS_HOME/config/ >>> gus.config. $GUS_CONFIG_FILE is no longer used anywhere in the >>> codebase. >>> >>> $GUS_HOME/config/gus.config is created at build time from >>> $PROJECT_HOME/install/gus.config. Thus, you should make changes >>> there and do a build to move them to $GUS_HOME if you need to make >>> config changes. >>> >>> Long Version: >>> >>> In 3.5, we had the gus.config file as well as the $GUS_HOME_CONFIG >>> file. The latter was generated by the former, and some components >>> used one while other components used the other. It thus became >>> confusion to know what configuration you were actually using, and >>> there was of course redundancy. This resolves that issue. An >>> outstanding issue remains how to provide functionality to easily >>> switch between multiple configurations. >>> >>> * (except when otherwise overridden on the command line) >>> _______________________________________________ >>> CBIL mailing list >>> CB...@pc... >>> https://mail.pcbi.upenn.edu/mailman/listinfo/cbil >>> >>> >>> >> >> _______________________________________________ >> ApiDB mailing list >> Ap...@pc... >> https://mail.pcbi.upenn.edu/mailman/listinfo/apidb >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > |
|
From: Deborah P. <pi...@pc...> - 2005-10-28 14:06:32
|
Michael Saffitz wrote: >One additional change: > >At install time, $PROJECT_HOME/install/gus.config.sample should be >moved and configured to $GUS_HOME/config/gus.config. This file (in >$GUS_HOME) will then be the sole configuration for GUS. > > This should be done manually? build = install ? >No components in GUS will use $PROJECT_HOME/install/gus.config >anymore, nor will it automatically be copied to $GUS_HOME/config/ >gus.config > >--Mike > >On Oct 27, 2005, at 10:05 PM, Michael Saffitz wrote: > > > >>All, >> >>I've finally fixed the long standing and often confusion generating >>issue of properly configuring GUS. This change should be relatively >>minor, and full details are below, but I wanted to make sure everyone >>was clear. >> >>Short Version: >> >>****** All GUS configuration* now comes from $GUS_HOME/config/ >>gus.config. $GUS_CONFIG_FILE is no longer used anywhere in the >>codebase. >> >>$GUS_HOME/config/gus.config is created at build time from >>$PROJECT_HOME/install/gus.config. Thus, you should make changes >>there and do a build to move them to $GUS_HOME if you need to make >>config changes. >> >>Long Version: >> >>In 3.5, we had the gus.config file as well as the $GUS_HOME_CONFIG >>file. The latter was generated by the former, and some components >>used one while other components used the other. It thus became >>confusion to know what configuration you were actually using, and >>there was of course redundancy. This resolves that issue. An >>outstanding issue remains how to provide functionality to easily >>switch between multiple configurations. >> >>* (except when otherwise overridden on the command line) >>_______________________________________________ >>CBIL mailing list >>CB...@pc... >>https://mail.pcbi.upenn.edu/mailman/listinfo/cbil >> >> >> > >_______________________________________________ >ApiDB mailing list >Ap...@pc... >https://mail.pcbi.upenn.edu/mailman/listinfo/apidb > > |
|
From: Michael S. <msa...@pc...> - 2005-10-28 13:59:36
|
One additional change: At install time, $PROJECT_HOME/install/gus.config.sample should be moved and configured to $GUS_HOME/config/gus.config. This file (in $GUS_HOME) will then be the sole configuration for GUS. No components in GUS will use $PROJECT_HOME/install/gus.config anymore, nor will it automatically be copied to $GUS_HOME/config/ gus.config --Mike On Oct 27, 2005, at 10:05 PM, Michael Saffitz wrote: > > All, > > I've finally fixed the long standing and often confusion generating > issue of properly configuring GUS. This change should be relatively > minor, and full details are below, but I wanted to make sure everyone > was clear. > > Short Version: > > ****** All GUS configuration* now comes from $GUS_HOME/config/ > gus.config. $GUS_CONFIG_FILE is no longer used anywhere in the > codebase. > > $GUS_HOME/config/gus.config is created at build time from > $PROJECT_HOME/install/gus.config. Thus, you should make changes > there and do a build to move them to $GUS_HOME if you need to make > config changes. > > Long Version: > > In 3.5, we had the gus.config file as well as the $GUS_HOME_CONFIG > file. The latter was generated by the former, and some components > used one while other components used the other. It thus became > confusion to know what configuration you were actually using, and > there was of course redundancy. This resolves that issue. An > outstanding issue remains how to provide functionality to easily > switch between multiple configurations. > > * (except when otherwise overridden on the command line) > _______________________________________________ > CBIL mailing list > CB...@pc... > https://mail.pcbi.upenn.edu/mailman/listinfo/cbil > |
|
From: Y. T. G. <yon...@pc...> - 2005-10-28 03:12:04
|
Which version of WDK did you use? I strongly recommend installing stable versions of WDK from download site= =20 (or tagged/branched versions, not trunk, from svn)=20 WDK 1.6 and 1.7 has been tested against postgres (which looks like is what= =20 you are trying to use), with the command you are running executed=20 successfully. The same tests was not repeated in WDK 1.8 but there were no= =20 code changes relevant to postgres. -Thomas On Thu, 27 Oct 2005, [ISO-8859-1] Henrique Juc=E1 wrote: > Hi. > > Thanks for the attention again =3D) > > I got this error while trying to create a toyModel (I guess this is > the last version): > > $ wdkTestDb -model toyModel -create > Loading table usertest.WDKTestEst to database from file > > ERROR: column "row_project_id" is of type numeric but expression is of > type character varying > java.sql.SQLException: ERROR: column "row_project_id" is of type > numeric but expression is of type character varying > at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(Q= ueryExecutorImpl.java:1471) > at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryEx= ecutorImpl.java:1256) > at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorI= mpl.java:175) > at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdb= c2Statement.java:392) > at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(Ab= stractJdbc2Statement.java:330) > at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(Abstr= actJdbc2Statement.java:282) > at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpda= te(DelegatingPreparedStatement.java:233) > at org.gusdb.wdk.model.implementation.SqlUtils.getResultSet(SqlUti= ls.java:51) > at org.gusdb.wdk.model.test.TestDBManager.main(TestDBManager.java:= 117) > > > > > Henrique Cesar Lemos Juc=E1 - http://www.bioinformatica.ufsc.br > > "As soon as you concern yourself with the "good" and "bad" of your fellow= s, > you create an opening in your heart for maliciousness to enter. Testing, > competing with, and criticizing others weaken and defeat you." > > Morihei Ueshiba, O-Sensei (1883-1969) > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > |
30 messages has been excluded from this view by a project administrator.
