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...> |