Re: [JIRA] Closed: (CAY-901) Cannot set more than one to-one relationship to null.

From: Kevin Menard (kmenar..ervprise.com)
Date: Thu Oct 25 2007 - 08:17:35 EDT

  • Next message: Andrus Adamchik (JIRA): "[JIRA] Created: (CAY-903) Support primitive types in DataObjects"

    Thanks for the quick fix. I was going to create a test case over the
    weekend, but looks like I don't need to now :-)

    -- 
    Kevin
    

    On 10/25/07 5:20 AM, "Andrus Adamchik (JIRA)" <de..ayenne.apache.org> wrote:

    > > [ > https://issues.apache.org/cayenne/browse/CAY-901?page=com.atlassian.jira.plugi > n.system.issuetabpanels:all-tabpanel ] > > Andrus Adamchik closed CAY-901. > ------------------------------- > > Resolution: Fixed > > fixed on 3.0M2 tag and trunk. Thanks Kevin for digging to the core of the > issue, so the fix only took 5 minutes for me > >> Cannot set more than one to-one relationship to null. >> ----------------------------------------------------- >> >> Key: CAY-901 >> URL: https://issues.apache.org/cayenne/browse/CAY-901 >> Project: Cayenne >> Issue Type: Bug >> Components: Cayenne Core Library >> Affects Versions: 3.0 >> Reporter: Kevin Menard >> Assignee: Andrus Adamchik >> Fix For: 3.0 >> >> >> Given three entities Person, Place, Thing. Person has a to-one relationship >> to Place. Person has a to-one relationship to Thing. Calling the following >> code does not work: >> person.setPlace(null); >> person.setThing(null); >> person.getObjectContext().commitChanges(); >> The place will be set to null, but the thing will not. The problem appears >> to be in DataDomainDBDiffBuilder#arcDeleted(). There, if the currentArcDiff >> is null, a new one is created and the arc deletion noted. If the >> currentArcDiff is not null, however, an arc deletion will only be added if >> the arcId has already been added to the map. In the case of the setThing() >> call, the currentArcDiff will not be null, containing the place deletion, but >> there will be no entry for the thing deletion. The thing deletion will not >> be added because of the blocking condition. >> It appears that either the condition needs to be removed or refined to >> account for such a situation. Given that I'm not clear on what the original >> intent was, it's hard to recommend a clear solution. Removing the condition >> fixed the problem in my codebase.

    --



    This archive was generated by hypermail 2.0.0 : Thu Oct 25 2007 - 08:18:29 EDT