On Nov 17, 2011, at 7:48 AM, Paul Hoadley wrote: > On 17/11/2011, at 10:08 AM, David Avendasora wrote: > >> On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: >> >>> Say I have two entities, User and Role, and a joining entity UserRole to >>> create a many-to-many relationship between them. So I have a relationship >>> 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role >>> back to UserRole). I flatten the relationship on User, so I also have a >>> 'roles' relationship on that entity. >> >> Wait. "Also"?!? That's insane. That's two distinct relationships >> representing the same DB information, and one is hiding a huge piece of the >> action. You are just asking for trouble. > > User.userRoles is not a class property. All that's exposed is the flattened > User.roles.
Okay, then that should be alright then, and I think nullify is the proper setting for the non-class "real" relationships. > I don't _think_ I'm talking about anything particularly unusual here, just > the standard result of creating a many-to-many relationship with Entity > Modeler, with a join entity and "Flatten relationships" checked. Not unusual, just something that you really shouldn't even be thinking about. That's what flattened relationships do to you. I don't like them. Every time I've tried to use them, I end up regretting it. I find it much better to leave the real relationship and write cover methods that approximate what flattening it would have done. That many-to-many join entity always seems to end up having additional parameters, or be just the right place to put a certain piece of business logic. Then I have to refactor everything that was dependent upon the flattened relationship. That and flattening mandates that you use compound primary keys, which are Evil. Evil like Vertical Inheritance and running without containment on your reactor … er … I mean without FK constraints defined in the database (yes, that was aimed at all you MySQL/MSSQL Reavers out there). All these technologies/features reside in the Eighth Circle of Hell (8th trench, to be specific.). They seem to be great time/money savers, but in the end they bind you to servicing their restrictive shortcomings and tempt you into further wobauchery like compound Foreign Keys and sharing individual attributes of compound Foreign Keys between multiple relationships. It's just sick what some people will do. I firmly believe that the only time you should use any of them is when you are given a legacy database that you have to write an app for. If you are creating the db to support your own App, don't be tempted by their siren call. I know that it's not a popular view, and likely Chuck or Mike or many others with greater experience will say that they can be used safely. They'll say things like "Flattened Many-to-Many Relationships don't kill apps, Developers kill apps." Flattened Many-toManys just make it so much easier. 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
