Re: duplicate pk error: recovering from

Chuck Hill <[email protected]>
Newsgroups gmane.comp.web.webobjects.eof
Message-ID <[email protected]>
A better question might be, "Why am I getting this duplicate PK error?"  It
seems to me that it would be better to avoid this than to recover from it.
The only time I've seen this happen is with a M-M join table with a complex
PK on the two FKs.  I don't know that this is your problem but assuming it
is...

In this situation if you remove one of the joins (using
removeObjectFrom...) and then replace it with an equivalent one (using
addObjectTo...).  The real problem here is that EOF does not order the
operations correctly, issuing the inserts before the deletes.

I don't think you can defer the unique constraint checking on a PK, so some
possible solutions are:
1. Order the database operations yourself
2. Add a generated PK to the join table as a third column
3. Change your code so that you never remove a join and then add an
equivalent.  This makes working with WOBrowser etc a tad more challenging.

You will probably find 2 to be the least time consuming.


Chuck

At 11:47 AM 03/01/2003 -0600, Jonathan Rochkind wrote:
>Let's say I know I'm about to perform an insert to the db which might 
>result in a "cannot insert duplicate pk" excpetion. I want to CATCH this 
>exception, and then RECOVER from it. That is, restore the EOF stack so it's 
>not trying to insert that bad EO anymore, it just gets rid of the bad EO.
>
>I can't quite figure out how to catch that exception, nor can I figure out 
>how to recover from it. At the moment, once that exception occurs, my 
>EOEditingContext is permanently polluted. Every time I try to saveChanges 
>on that EC again, it will again try to insert the duplicate pk, and again 
>get the exception.
>
>Anyone have any hints?
>
>--Jonathan
>
>_______________________________________________
>EOF mailing list
>[email protected]
>http://www.omnigroup.com/mailman/listinfo/eof
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.