Re: [Gusdev-gusdev] everything works except commit!

[Steve F. <sfi...@pc...>]

Michael-

let me try to cobble together an answer.   first, i am the culprit 
responsible for that plugin.   but, i think it should be ok.

about "sequences."    that term refers a database sequence, not a 
biological one.   it is a facility supported by oracle (and postgres) 
that provides an incremented number.    the plugins and object layer use 
such sequences to get the next primary key when inserting a row.

so, i suspect that your initial data in those tables was added "outside" 
the plugin structure.

i think the thing to do here is:
  1. avoid adding data without using either the plugins/object layer or 
using the sequence directly
  2. to correct the out-of-sync sequence, just run it in a loop 
advancing it past 3000 or whatever it needs to be.
  3. re-instate the code that uses the sequence

I would try that first, and then lets see if you still get the 
constraint errors.

steve

MICHAEL LUCHTAN wrote:

>Hello everyone-
>I have been attempting to load blast similarities into GUS with the plugin
>LoadBlastSimFast.pm after already loading some data in with the plugin
>LoadBlastSimilarityPK.pm (which was slow compared with the Fasst version).
>Well, the first thing that LoadBlastSimFast.pm does is start complaining
>about PrimaryKey uniqueness constraints being violated.  It used some
>fancy Oracle SQL that I didn't understand:
>select dots.similarity_SQ.NEXTVAL from DUAL
>Which by debugging I found out started at one, and increased each time we
>tested the plugin, regardless of commit not being turned on.  Naturally this crashed, because
>we already had about 3,000 entries in the dots.similarity table and
>we already had a sequence_id with value 1.  There
>was likewise a problem with the dots.similarityspan table.
>
>Since I only having a workingman's knowledge of OracleSQL, I switched it
>so that it starts with
>select count(*) from dots.similarity
>And increases this by one for each entry.  Likewise for
>dots.similarityspan.  This seemed to fix the problem, and the plugin works
>great on each file tested, claims to have entered all the correct data,
>and exits gracefully.  Yet when I run the same command line with --commit
>appended to the end, we start getting these Primary Key constraints
>violated errors again.
>
>Perhaps I do not understand what happens with commit.  I thought that
>these kind of errors would be caught with a regular run without commit
>turned on.
>Any help?
>
>
>
>
>Michael Luchtan
>http://www.cs.uga.edu/~luchtan
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>  
>