Re: Saving entities problem [SOLVED] {DONE -- FOR NOW}
Re: Saving entities problem [SOLVED] {DONE -- FOR NOW}
- Subject: Re: Saving entities problem [SOLVED] {DONE -- FOR NOW}
- From: Jonathan Rochkind <email@hidden>
- Date: Wed, 06 Aug 2003 10:42:20 -0500
At 08:26 AM 8/6/2003 -0700, Chuck Hill wrote:
>This hypothesis could be wrong but I believe what is happening is:
> aUsers.addObjectToBothSidesOfRelationshipWithKey(mlp,
"FLT_APPLICATIONS");
> //creates the first row in the join which will fail as there is no
>permission associated with the User and the Application
>
No. This creates no rows. It saves no data. All it does is to set a
property on aUsers and one on mlp.
Well, if the "FLT_APPLICATIONS" relationship is flattened, this will sort
of create the join object. I say 'sort of' becuase the join object may not
be visible from any public API (I'm not sure), but something inside EOF
knows that there's a newly inserted join object. Definitely it doesn't
save any data to the db; no data is ever saved to the db from EO operations
until you do ec.saveChanges(), of course.
Because this can get confusing, if you are having trouble with the
three-way join, I'd definitely abandon the flattened relationships. They
definitely could be making things fail in hard to understand and discover
ways. Once you get rid of the flattened relationships, it gets somewhat
easier to debug when there are problems. Using the flattened relationship
for a three-way join is an unusual situation that most developers haven't
played with, and that might trigger otherwise unseen bugs in EOF. But
without flattened relationshps, you are simply left with an entity that has
three relationships to three different entities, and has a compound primary
key made of those foreign keys. This is not that unusual, much less likely
to trigger previously undiscovered EOF bugs, much easier to debug, much
easier for other developers to help you debug.
--Jonathan
>aUsers.addObjectToBothSidesOfRelationshipWithKey(canUse, "FLT_PERMISSION");
> //creates another row in the join which will fail as there is no
>application associated with the User and the permission
>
No, see above. EOF might be creating extra rows at save time as it does
not know how to reuse the object above. Flattening might not work becuase
of this inability.
>I'm looking into extending the KeyValueCoding classes to create a
>method which will take 2 objects and 2 keys and then essentially create
>the relationships between all 3 entities.
> //Method Coming Soon (I Hope)
> aUsers.addObjectsToAllSidesOfRelationshipsWithKeys(mlp,
>"FLT_APPLICATIONS", canUse,"FLT_PERMISSION");
>
I fail to see how you could implement this any differently than the lines
above.
>For now what I have done is instantiated my 'Join' obj and set the the
>objects to it:
>
>USERAPPLICATIONPERMISSION uap = newUserApplicationPermission();
>uap.takeValueForKey(at, "users");
>uap.takeValueForKey(mlp, "applications");
>uap.takeValueForKey(canUse, "permission");
>
Me thinks this would be perferrable:
USERAPPLICATIONPERMISSION uap = newUserApplicationPermission();
// Don't forget this!!!!
at.editingContext().insertObject(uap);
uap.addObjectToBothSidesOfRelationshipWithKey(at, "users");
uap.addObjectToBothSidesOfRelationshipWithKey(mlp, "applications");
uap.addObjectToBothSidesOfRelationshipWithKey(canUse, "permission");
Instead of trying KVC magic why not just add a plain old Java method to User:
public void addApplicationPermission(Application anApplication, Permission
aPermission) {
USERAPPLICATIONPERMISSION uap = newUserApplicationPermission();
editingContext().insertObject(uap);
uap.addObjectToBothSidesOfRelationshipWithKey(this, "users");
uap.addObjectToBothSidesOfRelationshipWithKey(anApplication,
"applications");
uap.addObjectToBothSidesOfRelationshipWithKey(aPermission, "permission");
}
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.