You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Robert Zeigler <ro...@roxanemy.com> on 2012/03/26 23:41:03 UTC
Validating super/sub entity relationships, 3.1M3 vs. 3.0.2
I'm gradually migrating my projects to 3.1M3 from the 3.0 series. Today, I converted a project in the modeler and it now complains:
"Usage of super entity's relationships 'Entry.user' as reversed relationships for sub entity is discouraged"
I'm using single-table inheritance in this case, and "Entry" is the superclass, with two sub-classes. Every subclass needs a reference to the "user" table, so I put the relationship in the superclass rather than the subclasses. So my questions:
1) Why is this discouraged?
1b) What are the side-effects of maintaining the current mapping?
2) I suppose the "correct" thing is to remap this as one relationship to the user table for each subclass?
3) What change in behavior from 3.0.2 -> 3.1M3 warrants this new warning/preference? Or has it always been bad practice but now we're letting people know?
Robert
Re: Validating super/sub entity relationships, 3.1M3 vs. 3.0.2
Posted by Robert Zeigler <ro...@roxanemy.com>.
That would definitely help.
Robert
On Mar 27, 2012, at 3/272:55 AM , Andrus Adamchik wrote:
>> That said, the warning was pointing to the Entry entity, but I think the bad mapping was in the User entity. Maybe it's a matter of perspective? Or is that a bug?
>
> From the top of my head, Cayenne detects a cycle in relationship joins, but it can't tell which relationship in the pair a user might prefer to change (e.g. a relationship may only be relevant in subclass). So it takes a random guess. We should probably improve the error message to mention both relationships are candidates for refactoring.
>
> Andrus
>
>
> On Mar 27, 2012, at 12:48 AM, Robert Zeigler wrote:
>
>> After examining my project some more, I found the offending relationship.
>>
>> I have (generically):
>> Entry (to one)-> User
>> EntryType1 -> user (inherited from Entry)
>> EntryType2 -> user (inherited from Entry)
>>
>> And:
>> User (to many) => EntryType1
>>
>> The offending relationship was the User => EntryType1. Once I changed that to User => Entry, the project validated fine.
>> This makes sense: having User -> Entry and Entry -> User makes more sense than User -> EntryType1 and Entry -> User. The "bad" mapping is an artifact of having refactored the class hierarchy awhile ago.
>>
>> That said, the warning was pointing to the Entry entity, but I think the bad mapping was in the User entity. Maybe it's a matter of perspective? Or is that a bug?
>>
>> Robert
>>
>> On Mar 26, 2012, at 3/264:41 PM , Robert Zeigler wrote:
>>
>>> I'm gradually migrating my projects to 3.1M3 from the 3.0 series. Today, I converted a project in the modeler and it now complains:
>>>
>>> "Usage of super entity's relationships 'Entry.user' as reversed relationships for sub entity is discouraged"
>>>
>>> I'm using single-table inheritance in this case, and "Entry" is the superclass, with two sub-classes. Every subclass needs a reference to the "user" table, so I put the relationship in the superclass rather than the subclasses. So my questions:
>>>
>>> 1) Why is this discouraged?
>>> 1b) What are the side-effects of maintaining the current mapping?
>>> 2) I suppose the "correct" thing is to remap this as one relationship to the user table for each subclass?
>>> 3) What change in behavior from 3.0.2 -> 3.1M3 warrants this new warning/preference? Or has it always been bad practice but now we're letting people know?
>>>
>>> Robert
>>
>>
>
Re: Validating super/sub entity relationships, 3.1M3 vs. 3.0.2
Posted by Andrus Adamchik <an...@objectstyle.org>.
> That said, the warning was pointing to the Entry entity, but I think the bad mapping was in the User entity. Maybe it's a matter of perspective? Or is that a bug?
From the top of my head, Cayenne detects a cycle in relationship joins, but it can't tell which relationship in the pair a user might prefer to change (e.g. a relationship may only be relevant in subclass). So it takes a random guess. We should probably improve the error message to mention both relationships are candidates for refactoring.
Andrus
On Mar 27, 2012, at 12:48 AM, Robert Zeigler wrote:
> After examining my project some more, I found the offending relationship.
>
> I have (generically):
> Entry (to one)-> User
> EntryType1 -> user (inherited from Entry)
> EntryType2 -> user (inherited from Entry)
>
> And:
> User (to many) => EntryType1
>
> The offending relationship was the User => EntryType1. Once I changed that to User => Entry, the project validated fine.
> This makes sense: having User -> Entry and Entry -> User makes more sense than User -> EntryType1 and Entry -> User. The "bad" mapping is an artifact of having refactored the class hierarchy awhile ago.
>
> That said, the warning was pointing to the Entry entity, but I think the bad mapping was in the User entity. Maybe it's a matter of perspective? Or is that a bug?
>
> Robert
>
> On Mar 26, 2012, at 3/264:41 PM , Robert Zeigler wrote:
>
>> I'm gradually migrating my projects to 3.1M3 from the 3.0 series. Today, I converted a project in the modeler and it now complains:
>>
>> "Usage of super entity's relationships 'Entry.user' as reversed relationships for sub entity is discouraged"
>>
>> I'm using single-table inheritance in this case, and "Entry" is the superclass, with two sub-classes. Every subclass needs a reference to the "user" table, so I put the relationship in the superclass rather than the subclasses. So my questions:
>>
>> 1) Why is this discouraged?
>> 1b) What are the side-effects of maintaining the current mapping?
>> 2) I suppose the "correct" thing is to remap this as one relationship to the user table for each subclass?
>> 3) What change in behavior from 3.0.2 -> 3.1M3 warrants this new warning/preference? Or has it always been bad practice but now we're letting people know?
>>
>> Robert
>
>
Re: Validating super/sub entity relationships, 3.1M3 vs. 3.0.2
Posted by Robert Zeigler <ro...@roxanemy.com>.
After examining my project some more, I found the offending relationship.
I have (generically):
Entry (to one)-> User
EntryType1 -> user (inherited from Entry)
EntryType2 -> user (inherited from Entry)
And:
User (to many) => EntryType1
The offending relationship was the User => EntryType1. Once I changed that to User => Entry, the project validated fine.
This makes sense: having User -> Entry and Entry -> User makes more sense than User -> EntryType1 and Entry -> User. The "bad" mapping is an artifact of having refactored the class hierarchy awhile ago.
That said, the warning was pointing to the Entry entity, but I think the bad mapping was in the User entity. Maybe it's a matter of perspective? Or is that a bug?
Robert
On Mar 26, 2012, at 3/264:41 PM , Robert Zeigler wrote:
> I'm gradually migrating my projects to 3.1M3 from the 3.0 series. Today, I converted a project in the modeler and it now complains:
>
> "Usage of super entity's relationships 'Entry.user' as reversed relationships for sub entity is discouraged"
>
> I'm using single-table inheritance in this case, and "Entry" is the superclass, with two sub-classes. Every subclass needs a reference to the "user" table, so I put the relationship in the superclass rather than the subclasses. So my questions:
>
> 1) Why is this discouraged?
> 1b) What are the side-effects of maintaining the current mapping?
> 2) I suppose the "correct" thing is to remap this as one relationship to the user table for each subclass?
> 3) What change in behavior from 3.0.2 -> 3.1M3 warrants this new warning/preference? Or has it always been bad practice but now we're letting people know?
>
> Robert