Re: Saving entities problem [SOLVED]
Re: Saving entities problem [SOLVED]
- Subject: Re: Saving entities problem [SOLVED]
- From: Art Isbell <email@hidden>
- Date: Fri, 1 Aug 2003 10:24:54 -1000
On Friday, August 1, 2003, at 06:38 AM, Jevon Hills wrote:
> In the Database I have removed the 'one field pk' and set the three FK
> fields as a compound column PK. I have made changes in my EOModel to
> reflect this as well.
Were the changes you made consistent with the properties of a
many-to-many relationship that EOModeler can create? This is a crucial
starting point. You can unmark some of the class relationships if you
don't need them, but the other properties of the relationships are
crucial to make things work correctly. Then you must regenerate your
EO classes so the necessary methods exist.
> I think I understand, but would like to confirm by repeating it back.
> In the database I have 4 tables (Users, Applications, Permission and
> UserApplicationPermission). In the Database the
> UserApplicationPermission table has 3 FK's (the PK's of UsersID,
> ApplicationsID and PermissionID). At this point I have some say over
> the table as to whether or not it has it's own single field PK or we
> Use the CompoundField PK.
Either model should work, but the 3-way many-to-many should require
less coding since you can ignore the join entity.
> I started my WO application, by modeling the database directly, using
> the 'join' table in my EOModel as is. If I understand what you are
> suggesting. In EOModeler I should create a "Join Entity" which has
> no table in the DB. I can instantiate this obj in my code, insert it
> into my EditingContext and use it.
> Is this Correct?
No. Since you aren't forced to use a "join" entity with its own
single primary key attribute, you should be able to use a join entity
with a compound primary key (the foreign keys for the to-one
relationships to the User, Application, and Permission entities). In
doing so, you should be able to ignore the join entity in your code.
In fact, it could be marked "Abstract" since it will never be
instantiated on the client, but it does represent a real table in the
DB.
One way to create the correct many-to-many relationship in EOModeler
would be to have it create a many-to-many relationship between User and
Application. Then you'd need to enhance the resulting join entity by
adding another primary key which is the foreign key for the to-one
"permission" relationship. Then you'd add a to-many relationship from
Permission to the join entity whose name should be changed to reflect
its 3-entity join. Flatten the relationships from Permission to both
User and Application. Then you'd carefully set the properties of the 2
new relationships you just created to be identical to those created by
EOModeler when it created a many-to-many relationship between User and
Application.
Then you can decide whether you will really use all the the
relationships between these 4 entities. In relationship sets, if
relationships in both directions are class properties, EOF will usually
fetch more than is necessary to keep the object graph consistent if you
won't be traversing the object graph in both directions. I try to make
a relationship in only one direction a class property to minimize
unnecessary and performance-robbing fetches. This applies to all
relationships, not just many-to-many.
Finally, you'd create a real table in your DB that corresponds to the
join entity using the SQL that EOModeler generates. Or maybe you'd
modify the existing DB join table to reflect the entity ensuring that
the appropriate indexes, constraints, etc. in EOModeler's generated SQL
exist in the DB.
Aloha,
Art
_______________________________________________
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.