Re: [Gusdev-gusdev] GBParser

[Angel P. <an...@pc...>]

Thanks very much for writing this up Michael. It will eventually go into 
real GUS documentation ;)
Some additional comments below:
MICHAEL LUCHTAN wrote:

>Hey Jinal-
>It is kind of important to know what's going on with the algorithm_id.
>Almost every table in GUS has a field called row_alg_invocation_id that is
>a primary foriegn key.
>  
>
At the rick of throwing grease on the fire, you should know that as far 
as the plugin layer is concerned, this is a foriegn key. But the foreign 
key does not actaully exist in the database. We found that performance 
on deletes with respect to the AgloritmInvocation table was not feasible 
when the FK was actually enforced in the database.

>I will attempt to explain, and maybe someone can clarify my lack of
>knowledge.  But this is strongly tied to the whole ga/plugin structure.
>Every plugin that you use is an an algorithm.  When you use ga +create
>SomePlugin it puts an entry into the algorithm table for that plug-in, and
>I assume an  initial entry into the algorithmImplementation table.
>When you do a ga +update SomePlugin it puts a new entry into into the
>algorithmImplementation table with the same algorithm_id.  This way you
>can keep updating your plug-ins from CVS.  So, depending on how many times
>you run ga +update SomePlugin, you can have that many rows in
>algorithmImplementation with the algorithm_id that corresponds to
>SomePlugin.
>Once that's in there, every time you <i>use</i> SomePlugin, ga places an
>entry into algorithmInvocation, with a new algorithm_invocation_id , and
>an algorithm_implentation_id corresponding to the version of the plugin
>you are running.  This is usefull for when you have entered a bunch of
>data using SomePlugin, and then you find out that SomePlugin had a bug in
>it and you placed the data in an incorrect place, or entered incorrect
>data.  You can then remove everything that has the row_alg_invocation_id
>equal to the algorithm_invocation_id that messed up.
>Now, this collection of tables is really circular, with
>algorithmInvocation having a self-referential primary key, but I think
>that the install of GUS will take care of it.
>
Yes, the bootstraprow.sql file takes care of the circular reference.

>  I assume that ga itself is
>an algorithm.  My oracle is down right now so I can't check.
>I couldn't answer your question directly before because I distinctly
>remember entering a row in Algorithm once for an annotation ID, so if I
>don't know the particulars of the plugin, can't say for sure what you
>need.  But I might remember distinctly doing something wrong, since I was
>still quite the nube back then(now I am only a little less
>wet-behind-the-ears).  I don't know if every algorithm is a plugin, and
>every plugin is an algorithm(ie a one-to-one correspondence), or if every
>plug-in is an algorithm but not every algorithm is a plugin-- you know
>like all shriners are masons but not all masons are shriners.
>If anyone wants to clarify this, feel free.
>  
>
Every plugin is an algortihm, but not every algorithm is a plugin. For 
instance we have an "sqlplus" algorithm for insertions done through 
SQLPlus interface.
Angel

>Michael Luchtan
>http://www.cs.uga.edu/~luchtan
>
>  
>