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