[jira] Commented: (CAY-1009) Bogus runtime relationships can mess up commit.

["Kevin Menard (JIRA)" <de...@cayenne.apache.org>]

    [ https://issues.apache.org/cayenne/browse/CAY-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781#action_12781 ] 

Kevin Menard commented on CAY-1009:
-----------------------------------

It looks like these auto-created relationships also mess up the delete rule processing.  Using a NULLIFY rule, for instance, will remove the object from the runtime relationship store but not from the one I'm using via the explicitly named relationship.  The object does appear as deleted in my collection, but it shouldn't appear at all.

> Bogus runtime relationships can mess up commit.
> -----------------------------------------------
>
>                 Key: CAY-1009
>                 URL: https://issues.apache.org/cayenne/browse/CAY-1009
>             Project: Cayenne
>          Issue Type: Bug
>          Components: Cayenne Core Library
>    Affects Versions: 3.0
>            Reporter: Kevin Menard
>            Assignee: Andrus Adamchik
>
> I'm still the process of investigating this one, so more details to come.  Basically what I'm seeing is that if two ObjRels map to the same DbRel somehow and only one is mapped explicitly, the runtime one can fail validation while the specified one passes.  I'm observing this in a relationship that involves inheritance.  It looks like I've explicitly mapped an ObjRel for the subclass type and Cayenne is creating one for the base class.  The DbAttr is marked as required.  Since I never specify a value in the runtime relationship, since it's not mapped or useful to me, validation fails.  If I don't mark the attribute as mandatory, everything commits just fine.  So, I suspect Cayenne resolves the conflict somewhere down the line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (CAY-1009) Bogus runtime relationships can mess up commit.

[Kevin Menard <km...@servprise.com>]

Okay, I finally made some progress.  The issue seems to be that the way the
test stack is built bypasses a call to applyObjectLayerDefaults() in
EntityResolver.  It is this call that creates the bogus relationships, thus
me not being able to reproduce.

I still haven't managed to create the commit issue I saw before, but I think
this may be related to the problem in CAY-1008, whereby the first found
relationship is used.  I could be unlucky and the first found one is the
explicitly mapped one, not the runtime created one, which would cause things
to appear to work fine.

My gut feeling is that the problem is in
ObjRelationship#getReverseRelationship.  Particularly, line #191 has the
following check:

if (rel.getTargetEntity() != src)

I think that should probably be some sort of instanceof operation.  If
there's an explicit mapping to a subclass, we probably should consider that
good enough and not create a runtime relationship to the base class.  I'm
not sure of the full impact that change would make, however.

-- 
Kevin


On 3/15/08 3:15 PM, "Kevin Menard" <km...@servprise.com> wrote:

> Sorry for the delay in this.  The test case I thought I had was actually for
> CAY-1008, not CAY-1009.  I'm having difficulty reproducing this in people
> datamap.
> 
> The core issue I think is that if I explicitly map relationships to
> subclasses, a runtime relationship is created for the base class.  Then I
> think the same problem in CAY-1008 kicks in.  At this point I'm a bit at a
> loss as if the problem is more complicated than that or if my mapping is all
> whacked out.
> 
> For what it's worth, I've been trying to reproduce the problem using the
> AbstractPerson / CustomerRepresentative => ClientCompany relationship.  I
> haven't been able to induce the runtime relationship yet.

Re: [jira] Commented: (CAY-1009) Bogus runtime relationships can mess up commit.

[Kevin Menard <km...@servprise.com>]

Sorry for the delay in this.  The test case I thought I had was actually for
CAY-1008, not CAY-1009.  I'm having difficulty reproducing this in people
datamap.

The core issue I think is that if I explicitly map relationships to
subclasses, a runtime relationship is created for the base class.  Then I
think the same problem in CAY-1008 kicks in.  At this point I'm a bit at a
loss as if the problem is more complicated than that or if my mapping is all
whacked out.

For what it's worth, I've been trying to reproduce the problem using the
AbstractPerson / CustomerRepresentative => ClientCompany relationship.  I
haven't been able to induce the runtime relationship yet.

-- 
Kevin


On 3/14/08 1:40 PM, "Kevin Menard" <km...@servprise.com> wrote:

> On 3/14/08 1:19 PM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
> 
>> 
>> On Mar 14, 2008, at 6:50 PM, Kevin Menard (JIRA) wrote:
>> 
>>>  Basically what I'm seeing is that if two ObjRels map to the same
>>> DbRel somehow and only one is mapped explicitly
>> 
>> What scenario causes two ObjRels map to the same DbRel? Could you post
>> relevant XML?
> 
> I've put together a test case using the inheritance data set already in the
> test suite.  I'll commit that as a small, motivating example.

Re: [jira] Commented: (CAY-1009) Bogus runtime relationships can mess up commit.

[Kevin Menard <km...@servprise.com>]

On 3/14/08 1:19 PM, "Andrus Adamchik" <an...@objectstyle.org> wrote:

> 
> On Mar 14, 2008, at 6:50 PM, Kevin Menard (JIRA) wrote:
> 
>>  Basically what I'm seeing is that if two ObjRels map to the same
>> DbRel somehow and only one is mapped explicitly
> 
> What scenario causes two ObjRels map to the same DbRel? Could you post
> relevant XML?

I've put together a test case using the inheritance data set already in the
test suite.  I'll commit that as a small, motivating example.

-- 
Kevin

Re: [jira] Commented: (CAY-1009) Bogus runtime relationships can mess up commit.

[Andrus Adamchik <an...@objectstyle.org>]

On Mar 14, 2008, at 6:50 PM, Kevin Menard (JIRA) wrote:

>  Basically what I'm seeing is that if two ObjRels map to the same  
> DbRel somehow and only one is mapped explicitly

What scenario causes two ObjRels map to the same DbRel? Could you post  
relevant XML?

Andrus