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. :-)
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
>
>
>
>
>
>
_______________________________________________
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]
