On 2011-11-16, at 8:24 PM, David Avendasora wrote: > 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.
I have very rarely had that need to change a to-many relationship. In my experience, they are just an implementation artifact from having to use an RDBMS to store an object graph. Flattening and hiding the join table avoids adding artificial constructs to the Java code. A Good Thing (tm) IMO. Now if the join table is a real object in your system, then by all means don't flatten. > That and flattening mandates that you use compound primary keys, which are > Evil. I will argue that they are not evil if they consist only of immutable FKs. Otherwise, yes, avoid them unless you have a really good reason not to. And even then they must be immutable. > 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. That sounds like The Voice of Experience. :-P > 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. Yes, they can. And should be. > They'll say things like "Flattened Many-to-Many Relationships don't kill > apps, Developers kill apps." "Flattened Many-to-Many Relationships don't kill apps, Davids kill apps." > Flattened Many-toManys just make it so much easier. ... to write WO applications, yes. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects _______________________________________________ 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
