Menu
▾
▴
Re: [GUSDEV] new Undo plugin
|
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... |
