Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (nike.apache.org: domain of jbryanlewis@gmail.com
 designates 72.14.220.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=lc++KhLHel75v+BH72Vo6mDTXqcvvG5zBze+Kapwu/0ySmZs0orlEXzqSWQMSzdO+q
         55YaTvA8KrG2U9PqYta2AUuCz6U3J2p/w5rHWTPWO2YMMarUFsf/9/I7jefCz/w6/XTl
         DYhiqSPliQxL+W1GE4USDxHEfzJ7IFsRuAk0Q=
MIME-Version: 1.0
In-Reply-To: <n2o86f0c84d1004150932pcaefd972y50778c30592ae897@mail.gmail.com>
References: <n2o86f0c84d1004150932pcaefd972y50778c30592ae897@mail.gmail.com>
Date: Thu, 15 Apr 2010 14:43:26 -0400
Message-ID: <z2w86f0c84d1004151143t7add7cbfs9dfad9bc6efe8b8c@mail.gmail.com>
Subject: Re: OptimisticLocking exception during cascade delete
From: Bryan Lewis <jbryanlewis@gmail.com>
To: user@cayenne.apache.org
Content-Type: multipart/alternative; boundary=0023545bd638bf139f04844ade8a

--0023545bd638bf139f04844ade8a
Content-Type: text/plain; charset=ISO-8859-1

Hmm, that's very strange.  Now the double deletion isn't happening.  I don't
think I changed anything relevant but I can't make it happen now.  Oh well,
never mind.


On Thu, Apr 15, 2010 at 12:32 PM, Bryan Lewis <jbryanlewis@gmail.com> wrote:

> I have an entity Quote with a to-many relationship to QuoteCountry, and a
> cascade delete rule.  When I delete a quote object, Cayenne attempts to
> delete the QuoteCountry objects twice, I suspect because I also have a
> flattened relationship quote.countries (Quote -> QuoteCountry -> Country).
>
> I was googling for previous reports of this and found none, but I did come
> across an old copy of Cayenne's DataContext.java that explicitly checked for
> deleting twice in the presence of a flattened relationship.
>
> Normally this double deletion might not be noticed, but it throws an
> OptimisticLockException if optimistic locking is enabled on the Quote
> entity.  My current work-around is to disable OL on this entity only, which
> isn't a bad work-around for me.  BatchAction does:
>
>     int updated = statement.executeUpdate();
>     if (useOptimisticLock && updated != 1) {
>         //...
>         throw new OptimisticLockException(...);
>
>

--0023545bd638bf139f04844ade8a--