Menu
▾
▴
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-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: 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: 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: 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: 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: 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 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 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 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...> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X