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 protected])
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com
>>>>>>
>>>>>> This email sent to [email protected]
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list ([email protected])
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>>
>>>> This email sent to [email protected]
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/dleber_wodev%40codeferous.com
>>>
>>> This email sent to [email protected]
>>
>> ;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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
