Re: Many-to-Many Join Table PK
Re: Many-to-Many Join Table PK
- Subject: Re: Many-to-Many Join Table PK
- From: David LeBer <email@hidden>
- Date: Wed, 17 Nov 2010 09:50:30 -0500
On 2010-11-17, at 9:46 AM, David Avendasora wrote:
>
> On Nov 17, 2010, at 9:36 AM, David LeBer wrote:
>
>>
>> On 2010-11-17, at 9:23 AM, David Avendasora wrote:
>>
>>> Any further thoughts on this before I just remove the flattening and do things the "hard" way?
>>
>> It is and omnigroup hosted list:
>>
>> <http://www.omnigroup.com/mailman/listinfo/webobjects-talk>
>
> Thanks!
>
> But, I don't think this is the thread you think it is. :-)
Err, em, nothing to see here. Move along, move along.
>
> Dave
>
>>
>>>
>>> Dave
>>>
>>> On Nov 16, 2010, at 2:05 PM, David Avendasora wrote:
>>>
>>>> Okay. Busted. I was trying to obfuscate my actual model, and I did it wrong.
>>>>
>>>> Okay here's the real code (you all are sworn to double-super-secrecy):
>>>>
>>>> SchoolCompliance <->> SchoolComplianceRegistrationPeriod <<-> RegistrationPeriod
>>>>
>>>> SchoolCompliance has a compound PK of schoolId and complianceId
>>>> RegistrationPeriod has a simple PK of ID
>>>> SchoolComplianceRegistrationPeriod has a simple PK of ID
>>>> SchoolComplianceRegistrationPeriod.schoolCompliance joins on the schoolId and complianceId FKs
>>>> SchoolComplianceRegistrationPeriod.registrationPeriod joins on the registrationPeriodId FK
>>>>
>>>> I have a flattened schoolCompliances relationship on RegistrationPeriod that is defined as schoolComplianceRegistrationPeriods.schoolCompliance
>>>>
>>>> When I add a SchoolCompliance object to the RegistrationPeriod.schoolCompliances() toMany relatioinship, and then save it, I get:
>>>>
>>>> Caused by: java.lang.IllegalStateException: A valid global ID could not be obtained for entity named SamsSchoolComplianceRegistrationPeriod, relationship named schoolCompliances, primary key dictionary {schoolId = 1020; complianceId = 1000; registrationPeriodId = 15825; }.
>>>> at com.webobjects.eoaccess.EODatabaseContext.databaseOperationForIntermediateRowFromSourceObject(EODatabaseContext.java:4871)
>>>> at com.webobjects.eoaccess.EODatabaseContext.recordInsertForIntermediateRowFromSourceObject(EODatabaseContext.java:4888)
>>>> at com.webobjects.eoaccess.EODatabaseContext.relayAttributesInRelationshipSourceObjectDestinationObject(EODatabaseContext.java:4913)
>>>> at com.webobjects.eoaccess.EODatabaseContext.relayAttributesInRelationshipSourceObjectDestinationObjects(EODatabaseContext.java:4966)
>>>> at com.webobjects.eoaccess.EODatabaseContext.recordChangesInEditingContext(EODatabaseContext.java:6036)
>>>> at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:373)
>>>> at com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3192)
>>>> at er.extensions.eof.ERXEC._saveChanges(ERXEC.java:1085)
>>>> at er.extensions.eof.ERXEC.saveChanges(ERXEC.java:1007)
>>>> at com.k12.totalview.ui.RegistrationPeriodEdit.save(RegistrationPeriodEdit.java:165)
>>>>
>>>> The join table does NOT have a compound PK, why is EOF creating a PK-Dictionary with the FKs?
>>>>
>>>> Dave
>>>>
>>>> On Nov 16, 2010, at 12:54 PM, Mike Schrag wrote:
>>>>
>>>>> does one of the four relationships define the joins at be a composite rather than a single fk-pk join? it sort of looks that way, that the OrgRequirement.requirements relationship is defined wrong.
>>>>>
>>>>> On Nov 16, 2010, at 12:45 PM, David Avendasora wrote:
>>>>>
>>>>>> Just to be clear, here's the exception I get:
>>>>>>
>>>>>> Caused by: java.lang.IllegalStateException: A valid global ID could not be obtained for entity named OrgRequirement, relationship named requirements, primary key dictionary {orgId = 1020; requirementId = 1000;}.
>>>>>> at com.webobjects.eoaccess.EODatabaseContext.databaseOperationForIntermediateRowFromSourceObject(EODatabaseContext.java:4871)
>>>>>> at com.webobjects.eoaccess.EODatabaseContext.recordInsertForIntermediateRowFromSourceObject(EODatabaseContext.java:4888)
>>>>>> at com.webobjects.eoaccess.EODatabaseContext.relayAttributesInRelationshipSourceObjectDestinationObject(EODatabaseContext.java:4913)
>>>>>> at com.webobjects.eoaccess.EODatabaseContext.relayAttributesInRelationshipSourceObjectDestinationObjects(EODatabaseContext.java:4966)
>>>>>> at com.webobjects.eoaccess.EODatabaseContext.recordChangesInEditingContext(EODatabaseContext.java:6036)
>>>>>> at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:373)
>>>>>> at com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3192)
>>>>>> at er.extensions.eof.ERXEC._saveChanges(ERXEC.java:1085)
>>>>>> at er.extensions.eof.ERXEC.saveChanges(ERXEC.java:1007)
>>>>>>
>>>>>>
>>>>>> On Nov 16, 2010, at 9:32 AM, David Avendasora wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I have a Many-to-Many relationship and the join table does _not_ have a compound PK. It has a normal PK with a dataType of Long. The FKs that represent the to-One relationships on the join table are simply FKs and not part of the PK.
>>>>>>>
>>>>>>> I would like to flatten the toMany relationships, but when I add an object to the relationship and EOF tries to create a row in the join table it tries to create a compound PK for the join table, even though the Model is very clear as to what the PK is.
>>>>>>>
>>>>>>> Is this the normal EOF behavior to ignore the Model's PK settings for the join table and just assume that the PK is compound?
>>>>>>>
>>>>>>> I've always avoided flattened relationships because every time I try to use them I run into problems and give up and go back to regular relationships because it seems the work that flattened relationships save always gets offset by the limitations they impose (either that or my limitations of ability to use them properly).
>>>>>>>
>>>>>>> Dave
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> ;david
>>
>> --
>> David LeBer
>> Codeferous Software
>> 'co-def-er-ous' adj. Literally 'code-bearing'
>> site: http://codeferous.com
>> blog: http://davidleber.net
>> profile: http://www.linkedin.com/in/davidleber
>> twitter: http://twitter.com/rebeld
>> --
>> Toronto Area Cocoa / WebObjects developers group:
>> http://tacow.org
>>
>>
>>
>>
>>
>>
>
;david
--
David LeBer
Codeferous Software
'co-def-er-ous' adj. Literally 'code-bearing'
site: http://codeferous.com
blog: http://davidleber.net
profile: http://www.linkedin.com/in/davidleber
twitter: http://twitter.com/rebeld
--
Toronto Area Cocoa / WebObjects developers group:
http://tacow.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden